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VI. ISSUES 

VII. GROUPING OF CLAIMS 

VIII. ARGUMENTS 

ARGUMENT: VIIID - REJECTIONS UNDER 35 U.S.C. 103 

IX. APPENDIX OF CLAIMS INVOLVED IN THE APPEAL 

X. OTHER MATERIAL THAT APPELLANT CONSIDERS NECESSARY OR 
DESIRABLE 

The final page of this brief bears the practitioner's signature. 

I. REAL PARTY OF INTEREST (37 C.F.R. § 1 .192(c)(1)) 
The real party in interest in this appeal is Healthcare Vision, Inc. 

II. RELATED APPEALS AND INTERFERENCES (37 C.F.R. § 1.192(c)(2)) 
There are no appeals or interferences that will directly affect, or be directly affected by, 
or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS (37 C.F.R. § 1.192(c)(3)) 
The status of the claims in this application are: 

A. TOTAL NUMBER OF CLAIMS IN APPLICATION 
Claims in the application are: 35 claims. (Claims 1-35) 
Claims currently pending in the application: 35 pending claims 

B. STATUS OF ALL THE CLAIMS 

1 . Claims cancelled: NONE 

2. Claims withdrawn from consideration but not cancelled: NONE 

3. Claims pending: 1-35 

4. Claims allowed: NONE 

5. Claims rejected: 1-35 

C. CLAIMS ON APPEAL 

The claims on appeal are: 1-35 
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IV. STATUS OF AMENDMENTS (37 C.F.R. § 1.192(c)(4)) 
A Request for Reconsideration was filed on March 3, 2003. The Request for 
Reconsideration was not entered by the Examiner, as stated in paragraph 1 of the Examiner's 
Advisory Action dated March 21, 2003 (paper no. 18). The claims presently pending are those 
submitted October 9, 2002, in response to the non-final Office Action dated September 12, 2002 
(paper no. 12). 

V. SUMMARY OF THE INVENTION (37 C.F.R. § 1.192(c)(5)) 

The following summary is provided without any intention to limit the scope of the 
claims. The subject matter of claims 1-35 is summarized below. 

Claim 1 includes a system is provided for transferring electronic medical files. A record 
server has a medical record data file, the medical record data file has medical record data. A 
record client coupled to the record server receives the medical record data file. The medical 
record data is "encapsulated" to prevent modification of the medical record data. Page 15, lines 
8-24 lists examples of encapsulation. Claim 10 provides a related method that includes 
encapsulating medical record data to prevent it from being modified. 

Claim 16 includes a system for distributing medical supplies in which a record server 
receives package data. A record client coupled to the record server receives the package data 
from the record server and verification data. The record server receives the verification data 
from the record client and correlates the verification data to the package data. An example of a 
record client and record server that use package data and verification data in this manner is 
provided at paragraphs 0090 through 0095 of the specification and Figure 8. Claim 20 provides 
a related method that includes authorizing release of the package if stored package data, such as 
that from the record server, matches received package data, such as verification data or other 
suitable data from the record client. 

Claim 23 includes a system for transferring electronic medical files that includes a record 
server having an encapsulated medical record data file, the encapsulated medical record data file 
having medical record data that can be viewed but which cannot be modified. A record client is 
coupled to the record server and receives the encapsulated medical record data file. A sync 
system verifies that the record client has received sync data before transferring the encapsulated 
medical record data file. The record server further comprises a tracking system that updates a 
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tracking record when the encapsulated medical record data file is transferred, and the record 
client further comprises a tracking system that updates a tracking record when the encapsulated 
medical record data file is accessed. The record client further comprises a detail encapsulation 
system that receives comment data, encapsulates the comment data to prevent it from being 
modified, and stores the encapsulated comment data as part of the encapsulated medical record 
data file. The record client operates in unattended mode such that the encapsulated medical 
record data file can be received without an operator present. 

Claim 24 includes a method for transferring electronic medical data that includes 
determining whether a patient file having a predetermined patient data structure exists for a 
patient on a remote system. Electronic medical data is transferred to the patient file if it is 
determined that it exists, and the patient file is created with the predetermined patient data 
structure on the remote system if it is determined that the patient file does not exist on the remote 
system. The electronic medical data is then transferred to the newly created patient file on the 
remote system if it is determined that the patient file does not exist on the remote system. 

Claim 27 includes a method for transferring electronic medical record data that includes 
extracting an excerpt of the electronic medical record data from an electronic medical record data 
file at a first location. The excerpt is transmitted to a remote location, and comment data 
associated with the excerpt is received. The comment data is transmitted to the first location. 

Claim 29 includes a method for transferring electronic medical record data that 
comprises encapsulating an electronic medical record file so as to allow it to be viewed and to 
prevent it from being modified. The encapsulated electronic medical record file is then 
encrypted. The encrypted encapsulated electronic medical record file is then transmitted to a 
remote location. The encrypted encapsulated electronic medical record file is then decrypted at 
the remote location, and a user-readable display is generated using the encapsulated electronic 
medical record file. 

Narrower embodiments of the invention are described below. 

Claim 2 depends from claim 1 and provides that the record server further comprises a 
sync system verifying that the record client has received a sync file before transferring the 
medical record data file. 

Claim 3 depends from claim 1 and provides that the record server further comprises a 
tracking system updating a tracking record when the medical record data file is transferred. 
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Claim 4 depends from claim 1 and provides that the record client further comprises a 
tracking system updating a tracking record when the medical record data file is accessed. 

Claim 5 depends from claim 1 and provides that the record client further comprises a 
remote data system, the remote data system generating medical record data, wherein the record 
client encapsulates the medical record data to prevent it from being modified. 

Claim 6 depends from claim 1 and provides that the record client system further 
comprises a detail encapsulation system receiving comment data and encapsulating the comment 
data to prevent it from being modified. 

Claim 7 depends from claim 1 and provides that the record server further comprises a 
record storage system, the record storage system storing each version of the medical record data 
file received by the record server. 

Claim 8 depends from claim 1 and provides that the record server further comprises an 
excerpt transfer system, the excerpt transfer system receiving medical record excerpt data and 
transferring it to a predetermined recipient. 

Claim 9 depends from claim 1 and provides a notification system transferring notification 
data to a party regarding the availability of medical record data. 

Claim 11 depends from claim 10 and provides that transferring the medical record data 
file to the remote location further comprises transferring a sync file to the remote location. 

Claim 12 depends from claim 10 and provides that assembling the medical record data 
into the medical record data file further comprises storing a tracking record with the medical 
record data file. 

Claim 13 depends from claim 10 and provides generating notification data at the remote 
location. 

Claim 14 depends from claim 10 and provides accessing the medical record data file at 
the remote location; and updating a tracking record to show that the medical record data file has 
been accessed at the remote location. 

Claim 15 depends from claim 10 and provides receiving medical record data at the 
remote location; encapsulating the medical record data to prevent the medical record data from 
being modified; and updating the medical record data file to include the medical record data. 

Claim 17 depends from claim 16 and provides an inventory tracking system receiving the 
verification data and incrementing order data. 
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Claim 18 depends from claim 16 and provides a record encapsulation system receiving 
the verification data and encapsulating the verification data in a medical record data file. 

Claim 19 depends from claim 16 and provides a remote data system generating 
counseling data and transmitting the counseling data to the record server. 

Claim 21 depends from claim 20 and provides that receiving the package data from the 
remote site further comprises counseling a patient if the patient has not received the medical 
supplies before; and generating counseling data. 

Claim 22 depends from claim 20 and provides incrementing order data after the package 
is released. 

Claim 25 depends from claim 24 and provides that the remote system operates in an 
unattended mode that allows the electronic medical data to be transferred without operator input. 

Claim 26 depends from claim 25 and provides that the remote system receives electronic 
medical data for two or more users in unattended mode, and each user must enter a user-specific 
access ID to access the electronic medical data for that user. 

Claim 28 depends from claim 27 and provides that extracting an excerpt of the electronic 
medical record data from the electronic medical record data file comprises removing user- 
readable patient identifying data. 

Claim 30 depends from claim 29 and provides that the electronic medical record file is an 
image data file. 

Claim 31 depends from claim 2 and provides that the sync file is a patient file. 

Claim 32 depends from claim 1 and provides that the medical record client operates in 
unattended mode, so as to allow the medical record data file to be received without user input. 

Claim 33 depends from claim 1 1 and provides that transferring the sync file comprises 
creating a patient folder. 

Claim 34 depends from claim 16 and provides that the record client further comprises a 
data reader that reads the verification data from the package. 

Claim 35 depends from claim 16 and provides that the record client further comprises an 
image data capture device that generates image data, and the verification data includes the image 
data. 
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VI. ISSUES ((37 C.F.R. § 1.192(c)(6)) 
Whether claims 24 and 27 are unpatentable under 35 U.S.C. § 102(b) over Evans. 
Whether claims 1-15, 23, 28-29, 30-31, and 33 are unpatentable under 35 USC § 103(a) 

over Evans in view of McGauley. 

Whether claims 16, 17, 19, and 35 are unpatentable under 35 U.S.C. § 103(a) over Evans 

in view of Portwood. 

Whether claim 18 is unpatentable under 35 U.S.C. § 103(a) over Evans and Portwood in 
view of McGauley. 

Whether claims 25, 26, and 32 are unpatentable under 35 U.S.C. § 103(a) over Evans. 
Whether claim 34 is unpatentable under 35 U.S.C. § 103(a) over Evans and Portwood in 
view of Chudy. 

Evans - U.S. Patent No. 5,924,074 
McGauley -U.S. Patent No. 5,899,998 
Portwood -U.S. Patent No. 6,305,377 
Chudy - U.S. Patent No. 6,370,841 

VII. GROUPING OF CLAIMS ((37 C.F.R. § 1.192(c)(6)) 
The following claim groupings are considered as standing or falling separately: 

(a) Claims 24-28 

(b) Claims 1-15, 23 and 29-33 

(c) Claims 16-22, 34 and 35 

(d) Claims 2, 11,23,31 and 33 

The reasons for separate patentability are set forth below. 
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VIII. ARGUMENTS ((37 C.F.R. § 1.192(c)(6)) 
ARGUMENT: VIIIC - REJECTIONS UNDER 35 U.S.C. 102 (37 C.F.R. § 1.192(c)(8)(iii)) 

1. Background to Presently Claimed Invention 

The presently claimed invention provides a method for electronic medical file 
management that resolves problems that exist with prior art systems, mainly in the area of data 
security. In one exemplary embodiment, it is first determined whether a patient file having a 
predetermined patient data structure exists for a patient on a remote system. Electronic medical 
data is transferred to the patient file if it is determined that it exists, and the patient file is created 
with the predetermined patient data structure on the remote system if it is determined that the 
patient file does not exist on the remote system. The electronic medical data is then transferred 
to the newly created patient file on the remote system if it is determined that the patient file does 
not exist on the remote system. In another exemplary embodiment, an excerpt of the electronic 
medical record data is extracted from an electronic medical record data file at a first location. 
The excerpt is transmitted to a remote location, and comment data associated with the excerpt is 
received. The comment data is transmitted to the first location. 

2. Evans 

Evans discloses an electronic medical records system with limited data security. Some of 
the features described in the patent are as follows: 

(1) A patient data repository 102 that stores all of the patient data in a single location. 
See column 5, line 1 through column 5, line 20 of Evans. 

(2) Point of care systems 100 that obtain a patient record 111 from the patient data 
repository 102. 

(3) A new form window with edit functionality. See Figure 6. 

(4) An annotate window with edit functionality. See Figure 7. 

(5) A viewer window displaying an image of patient data with edit functionality. See 
Figure 8. 

(6) A diagnosis module and a procedure module with "remove" and "clear" functionality. 
See Figure 20. 

(7) A graphical user interface for a medication manager with "edit," "clear," and "remove 
all" functionality. See Figure 21. 
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The Evans patent describes many other features which are not relevant to the present 
invention. 

3. Patentability of claims 24 through 28 

Electronic medical record data can be inadvertently misused by importing the patient 
record of the wrong patient, such as where two patients have the same name, where the patient's 
name is spelled incorrectly, where a social security number is incorrectly entered, or in other 
circumstances. In one exemplary embodiment, the method of claims 24 through 28 prevents 
such errors by determining whether a patient file having a predetermined patient data structure 
exists for a patient on a remote system and creating the patient file with the predetermined 
patient data structure on the remote system if it is determined that the patient file does not exist 
on the remote system. The Examiner's construction of claims 24 through 28 would allow such 
errors to occur, and thus reads limitations out of the claims. Federal Circuit precedent prohibits 
construing claims in a manner that reads elements out of the claim. Texas Instruments v. U.S. 
Int'l Trade Comm'n, 988 F.2d 1165, 1171 (Fed. Cir. 1993). 

Claim 24 includes "determining whether a patient file having a predetermined patient 
data structure exists for a patient on a remote system, transferring the electronic medical data to 
the patient file if it is determined that it exists, creating the patient file with the predetermined 
patient data structure on the remote system if it is determined that the patient file does not exist 
on the remote system; and transferring the electronic medical data to the newly created patient 
file on the remote system if it is determined that the patient file does not exist on the remote 
system." The Examiner construed these elements to be that disclosed at column 8, lines 21-60 
and Figures 1 and 13 of Evans. Claim construction is reviewed de novo by the Board of Patent 
Appeals and Interferences. Further, it is axiomatic that "that which anticipates if earlier infringes 
if later." Thus, it needs to be determined de novo whether the method disclosed in Evans would 
infringe the proper construction of claim 24. 

The cited sections of Evans disclose a patient data repository 102 that has patient files 
having a predetermined data structure. See Figure 13 of Evans. When a remote system such as 
that disclosed at column 2, lines 29-55 of Evans requires a patient record, it "obtains the patient 
record 111 from the patient data repository 102. . At the conclusion of the patient's visit, the 
EMR system files the patient's record 119 in the patient data repository 102." Evans, col. 5, 
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lines 33-55. Figure 13 shows the "structure of a patient record." Evans, col. 4, lines 8-9. This 
structure is only present at the remote location when patient record 1 1 1 is obtained from patient 
data repository 102 when it is required by the remote system, such as prior to a patient 
appointment. It is then returned as patient record 119 to patient data repository 102 after the 
appointment, in order to maintain record integrity. Thus, the system of Evans disclosed in the 
sections cited by the Examiner fails to disclose "determining whether a patient file having a 
predetermined patient data structure exists for a patient on a remote system; transferring the 
electronic medical data to the patient file if it is determined that it exists; creating the patient file 
with the predetermined patient data structure on the remote system if it is determined that the 
patient file does not exist on the remote system; and transferring the electronic medical data to 
the newly created patient file on the remote system if it is determined that the patient file does 
not exist on the remote system." Instead, the entire patient record 1 1 1 is obtained from the 
patient data repository 102 at the remote system each time it is needed, and is returned to the 
patient data repository 102 as patient record 119 when it is no longer needed. There is no step of 
"determining whether a patient file having a predetermined patient data structure exists for a 
patient on a remote system," because the patient record 1 1 1 is transferred from the patient data 
repository 102 at the beginning of each session at the remote location and is returned as patient 
record 119 to the patient data repository 102 at the completion of the session at the remote 
location. There is also no "transferring the electronic medical data to the patient file if it is 
determined that it exists," because it never exists until patient record 1 1 1 is transferred, at which 
point no further transferring of data is performed. Because Evans would not infringe claim 24 as 
properly construed, the Examiner's construction is incorrect and should be reversed. 

Claim 25 depends from claim 24 and includes the remote system operating in an 
unattended mode that allows the electronic medical data to be transferred without operator input. 
The Examiner construed this to be "merely automatically updating or transferring the data 
without operator input." However, this construction reads the limitation of transferring the data 
to the remote location without operator input out of the claim - Evans discloses that the EMR 
system at the remote location obtains the patient record 111, such as when an appointment is 
scheduled. Evans, col. 5, lines 29-32. The patient data repository 102 cannot initiate the 
transfer. Thus, the construction adopted by the Examiner reads out the limitation that the data is 
transferred to the remote location without operator input. Furthermore, the Examiner's 
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construction reads out the limitation that the remote location is operating in an unattended mode 
- "merely automatically updating or transferring data without operator input" does not require 
the remote location to be operating in any particular mode, and can be performed while the 
remote location is attended. Therefore, the Examiner's construction of claim 25 improperly 
reads limitations out of the claim and should be reversed. 

Claim 26 depends from claim 25 and includes that the remote system receives electronic 
medical data for two or more users in unattended mode, and each user must enter a user-specific 
access ID to access the electronic medical data for that user. Again, the Examiner's construction 
(which is the same as claim 25) reads limitations out of the claim, such as the unattended mode 
allowing data for different users to be received and that a user-specific password can be required 
to access the data. "Merely automatically updating or transferring data without operator input" 
does not include the limitations of an unattended mode at the remote system, data being received 
for different users, and user-specific passwords being used to access the data received in 
unattended mode. As such, the Examiner's construction is incorrect and should be reversed. 

The Examiner construed claim 27 to be that disclosed by column 3, lines 36-42, column 4 
line 64 to column 5 line 8, and column 6, lines 31-36 of Evans, and Figure 4 of Evans. The 
Examiner further construed the claim as follows: "The Examiner considers the progress notes 
(144, Fig. 4) to be transferred from healthcare providers to another." As previously described, 
Evans discloses the transfer of the entire patient record 111 from the patient data repository 102 
to the remote location, and return of the entire patient record 119 to the patient data repository 
102 at the conclusion of the patient's visit. At column 3, lines 36-42 of Evans, transferring 
patient data from an external source to the electrical medical records system is disclosed. This 
refers to interfacing with external data sources that do not use the patient record 1 1 1 data format 
in the patient data repository. See, e.g., Evans, col. 10, line 18 through col. 11, line 9. A 
communication interface 274 is used to convert "external patient data into formats recognized by 
the EMR system." At column 4 line 64 to column 5 line 8, the general process of receiving data 
from external sources is disclosed. At column 6, lines 31-36 of Evans, progress notes 144 are 
described as being added to the patient record 111, and not to an excerpt of that record. The 
entire patient record 119 (including the progress notes 144) is then returned to the patient data 
repository 102, such that the entire patient record 1 1 1 (and not just an excerpt) must be obtained 
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in order to get the progress notes. The construction adopted by the Examiner is incorrect, and 
therefore, the rejection should be reversed. 

Claim 27, properly construed, includes "extracting an excerpt of the electronic medical 
record data from an electronic medical record data file at a first location; transmitting the excerpt 
to a remote location; receiving comment data associated with the excerpt; transmitting the 
comment data to the first location." Thus, the system of Evans would not infringe claim 27. The 
system of Evans does not extract an excerpt of the electronic medical record data from an 
electronic medical record data file at a first location and transmit the excerpt to a remote 
location, but instead transmits the entire patient record 111 to a remote location. Although data 
can be received from external sources, such external sources do not provide comment data in 
response to excerpt data. The only comment data that is received by a user of the system of 
Evans is transmitted with the entire patient record 111. One advantage of the claimed invention 
is that the entire patient record 1 1 1 does not need to be transmitted to a remote location in order 
to receive comment data - using the system of Evans, transmission of the entire patient record 
1 1 1 to remote locations via many common handheld devices would not be possible, either due to 
bandwidth or memory constraints of such handheld devices and the associated communications 
media. As such, the Examiner's construction of claim 27 improperly reads limitations out of the 
claim and should be reversed. 

Claim 28 depends from claim 27 and states that extracting an excerpt of the electronic 
medical record data from the electronic medical record data file comprises removing user- 
readable patient identifying data. The Examiner construes this claim as being transferring 
"patient data from the electronic medical records system to other healthcare providers and 
between external sources." Paper no. 12, page 4. However, this construction plainly reads out 
the limitation of "removing user-readable patient identifying data." Some of the "external 
sources" listed in Evans at column 3, lines 36-42 and column 4 line 64 to column 5 line 8 include 
physicians, hospitals, laboratories, and clinics, and some of the data includes laboratory results 
and prescriptions. What value are laboratory results and prescriptions to a physician or clinic if 
not accompanied by user-readable patient identifying information? The Examiner's construction 
of this claim fails to meet the requirements set forth by the Federal Circuit. 
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VIII. ARGUMENTS ((37 C.RR. § 1.192(c)(6)) 
ARGUMENT: VIIID - REJECTIONS UNDER 35 U.S.C. 103 (37 C.F.R. § 1 .192(c)(8)(iv)) 

1. Background to Presently Claimed Invention 

In one exemplary embodiment, the presently claimed invention provides a system for 
transferring electronic medical files that includes a record server having a medical record data 
file, the medical record data file having medical record data; a record client coupled to the record 
server, the record client receiving the medical record data file; and wherein the medical record 
data is encapsulated to prevent modification of the medical record data. 

In another exemplary embodiment, the presently claimed invention provides a method for 
transferring electronic medical files that includes encapsulating medical record data to prevent it 
from being modified; assembling the medical record data into a medical record data file; 
receiving a request to transfer the medical record data file; and transferring the medical record 
data file to a remote location. 

In another exemplary embodiment, the presently claimed invention provides a system for 
distributing medical supplies that includes a record server receiving package data; a record client 
coupled to the record server, the record client receiving the package data from the record server 
and verification data; and wherein the record server receives the verification data from the record 
client and correlates the verification data to the package data. 

In another exemplary embodiment, the presently claimed invention provides a method for 
distributing medical supplies that includes storing package data corresponding to a sealed 
package; transmitting the sealed package to a remote site; receiving the package data from the 
remote site; and authorizing release of the package if the stored package data matches the 
received package data. 

In another exemplary embodiment, the presently claimed invention provides a method for 
transferring electronic medical record data comprising: encapsulating an electronic medical 
record file so as to allow it to be viewed and to prevent it from being modified; encrypting the 
encapsulated electronic medical record file; transmitting the encrypted encapsulated electronic 
medical record file to a remote location; decrypting the encrypted encapsulated electronic 
medical record file at the remote location; and generating a user-readable display using the 
encapsulated electronic medical record file. 
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2. Evans 

The disclosure of Evans has previously been summarized. 

3. McGaulev 

McGauley discloses a system for maintaining and updating computerized medical 
records. Some of the features described in the patent are as follows: 

(1) A portable data carrier 100 carried by each patient, such as a smart card, that contains 
the patient's complete medical history. See Abstract and column 5, lines 51 through line 67 of 
McGauley. 

4. Portwood 

Portwood discloses a system for improving compliance of a medical regimen. Some of 
the features described in the patent are as follows: 

(1) Transmitting patient data to a physician after the patient has received a prescription 
and reminder data to the patient after the patient has received the prescription. Abstract. 

(2) Server computer that serves as a database for prescriber computer systems. Col. 3, 
lines 43-49. 

(3) A prescriber computer station B that provides prescription information for a patient. 
Column 6, line 37 through line 57. 

(4) A server that validates, certifies, and distributes prescription data to a prescription 
distribution company, such as a pharmacy or drug wholesale company. Column 7, line 11 
through 14 and lines 35-37. 

5. Chudv 

Chudy discloses an automated method for dispensing bulk medications with a machine- 
readable code. System 200 of Chudy shows a large assembly-line that is used to dispense the 
bulk medications from a plurality of bulk storage tablet cassettes 20 using a machine-readable 
code. 
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6. Patentability of independent claims 1 through 15, 23 and 29 through 33 

Electronic medical record reliability is an issue that has delayed the migration of medical 
records from hardcopy formats to electronic formats. Currently, hardcopy formats of medical 
records can be reviewed to determine whether changes were made, such as to determine whether 
a practitioner went back to modify a record so as to correct a misdiagnosis or otherwise cover up 
a mistake. Likewise, it is difficult to inadvertently destroy a hardcopy format of a medical 
record, whereas electronic files can be readily erased either intentionally or inadvertently. The 
invention of claims 1-15, 23, and 29-33 can be used to ensure that electronic medical records 
have not been tampered with, and to prevent the inadvertent or intentional destruction of 
electronic medical records. The construction of these claims adopted by the Examiner would not 
provide such functionality. 

Claim 1 includes "a record server having a medical record data file, the medical record 
data file having medical record data; a record client coupled to the record server, the record 
client receiving the medical record data file; and wherein the medical record data is encapsulated 
to prevent modification of the medical record data." The Examiner construed Claim 1 to be that 
disclosed at column 12, lines 56-63 and Figure 24, items 406, 408, and 410 of Evans, which 
discloses a wide area network connecting local area networks, and column 6, lines 44-48 of 
McGauley, which discloses encryption of data during transmission between two computers. The 
Examiner further construes claim 1 as follows in the final office action, paper no. 12, at page 12; 
"the McGauley reference describes encryption of medical record for the purpose of preventing 
and preserving the confidentiality of the individual patient's medical information. This is a clear 
indication that the medical information is encapsulated by encryption and cannot be modified." 

As a preliminary matter, it is not clear what "the purpose of preventing and preserving the 
confidentiality of the individual patient's medical information" means. Presumably, this means 
"preventing modification," but McGauley discloses that once the file is received, it can be 
modified. See, e.g., McGauley, Figure 6, update object manager 118 at point of service station 
110, and col. 12, lines 37-43 ("The data engine 119 controls the storage and retrieval of data 
from the database storage subsystem. The data engine is coupled to both the record object 
manager 117 and the update object manager 118. Collectively, these two object managers 
contain the rule sets by which medical information objects are processed according to the 
processing tags embedded within the data objects.") As the system of McGauley allows the 
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medical record data to be modified after it is received at point of service station 110 by the 
update object manager 118, it is clear that the encryption of McGauley is not encapsulation "to 
prevent modification of the medical record data." Furthermore, as previously noted, the system 
of Evans also provides the user with the capability to edit the medical record data. See, e.g., 
Evans, Figures 6, 7, 8, 20, and 21. Thus, the combination of Evans and McGauley would also 
result in a system in which the encrypted data is decrypted at the point of service to allow 
modification. Finally, claim 1 does not limit encapsulation of the medical record data to a 
process that is performed when the medical record data is transmitted from the record server to 
the record client, as disclosed in McGauley, but instead provides that "the medical record data is 
encapsulated to prevent modification of the medical record data." 

By insisting that encapsulation be construed to be synonymous with encryption, the 
Examiner ignores the mandate that "a patentee is free to be his own lexicographer." Markman v. 
Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (in banc), aff'd, 517 U.S. 370 
(1996). This allows a patentee to "coin a new expression with which to communicate the 
invention." Lear Siegler, Inc. v. Aeroquip Corp., 733 F.2d 881, 889 (Fed. Cir. 1984). Although 
the scope of encapsulation is defined by the claims, an example of encapsulation is provided at 
paragraph [0036] of the specification of the present application, where it is noted that in "one 
exemplary embodiment, record encapsulation system 302 includes encryption algorithms that 
generate a value based upon the exact data structure of the entire medical record data file, such 
that any modifications to the medical record data file can be detected." Thus, in this exemplary 
embodiment, encapsulation includes the use of the value that is based on the exact data structure 
of the entire medical record to detect modification. Merely encrypting data that is being 
transmitted between two points is not encapsulation of the medical record data to prevent 
modification, as that data could be intercepted by a third party after transmission, modified, and 
then re-transmitted to the intended recipient, who would never know that the data had been 
modified. The Examiner's construction of this claim element as being that which is disclosed at 
McGauley, col. 6, lines 44-48 is therefore incorrect. 

The Examiner's construction of encapsulation also violates the prohibition against 
construing claims in a manner that reads elements out of the claim, as it equates a process that 
occurs to a data record (encapsulation) with a process that occurs to a data stream as it is being 
transmitted (encryption). For example, claim 10 includes "encapsulating medical record data to 
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prevent it from being modified; assembling the medical record data into a medical record data 
file; receiving a request to transfer the medical record data file; and transferring the medical 
record data file to a remote location." The encapsulation of claim 10 thus occurs before the 
medical record data is assembled into a medical record data file, and before the request to 
transfer the medical record data file is received, unlike the process described in McGauley at 
column 6, lines 44-48, as relied on by the Examiner in rejecting claim 10, where the data is 
encrypted as it is being transmitted, only after the medical record data has been assembled into a 
medical record data file and after a request to transfer the medical record data file has been 
received. Thus, the Examiner's construction of claim 10 is also incorrect. 

Claim 23 includes "a record server having an encapsulated medical record data file, the 
encapsulated medical record data file having medical record data that can be viewed but which 
cannot be modified." The Examiner again relies on the point-to-point encryption disclosed at 
McGauley, column 6, lines 44-48, to reject claim 23, resulting in a construction of claim 23 that 
is improper. The point-to-point encryption of McGauley does not allow encrypted medical 
record data to be viewed - it must first be decrypted. Claim 23 further includes "the record 
client further comprising a detail encapsulation system receiving comment data, encapsulating 
the comment data to prevent it from being modified, and storing the encapsulated comment data 
as part of the encapsulated medical record data file." Again, the construction of encapsulation to 
be synonymous to point-to-point encryption is incorrect, as McGauley does not disclose that the 
encrypted data is ever stored, much less that comment data can be encrypted separately from the 
medical record data file. The construction of claim 23 put forth by the Examiner does not allow 
the patentees to be their own lexicographer and reads limitations out of the claim, and is 
therefore improper and should be reversed. 

Claim 29 includes "encapsulating an electronic medical record file so as to allow it to be 
viewed and to prevent it from being modified; encrypting the encapsulated electronic medical 
record file; transmitting the encrypted encapsulated electronic medical record file to a remote 
location; decrypting the encrypted encapsulated electronic medical record file at the remote 
location; and generating a user-readable display using the encapsulated electronic medical record 
file." Again, the Examiner construes encapsulation to be the same as the point-to-point 
encryption disclosed by McGauley at column 6, lines 44-48, which is flawed as described above, 
because a user-readable display cannot be generated using the point-to-point encrypted data, nor 
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does McGauley describe that the electronic medical record file is encrypted a first time and then 
encrypted a second time, and then transmitted, and then decrypted a first time, and that the still- 
encrypted electronic medical record data file is then viewed. The Examiner further admits that 
Evans teaches that a "nurse with the authorization . . . [can] update certain aspects" of the patient 
record 1 1 1 of Evans, which conclusively establishes that Evans in view of McGauley fails to 
disclose encapsulation to prevent modification. The construction adopted by the Examiner is 
incorrect, and therefore, the rejection should be reversed. 

Claim 3 depends from claim 1 and includes that the record server further comprises a 
tracking system updating a tracking record when the medical record data file is transferred. The 
Examiner construes this to be that which is disclosed at Evans column 9, lines 27-37, which 
states that the "data manager 202 likewise tracks the location and description of patient data 
within the data archive 208 by associating the file name of the patient data within a patient 
record 220 with the patient identifier 221." However, this construction reads the limitation of 
"updating a tracking record when the medical record data file is transferred" out of the claim. It 
is clear from the cited section of Evans that what is disclosed is a process for tracking the 
location of data within a data archive - a tracking record for tracking when a medical record data 
file is transferred is not disclosed by Evans. This process can be used to create an audit log, so as 
to determine when a user accessed a medical record data file. The construction adopted by the 
Examiner would not allow an audit log to be created, and only tracks the location of data within 
a data archive. The construction adopted by the Examiner is incorrect, and therefore, the 
rejection should be reversed. 

Likewise, claim 4 depends from claim 1 and includes that the record client further 
comprises a tracking system updating a tracking record when the medical record data file is 
accessed. Again, the Examiner's construction in paper no. 8 at page 4 reads this limitation out of 
the claim - "[t]his limitation is met by the electronic medical record system that includes server 
(406 Fig. 24) that are connected to client machines running applications such as Microsoft 
Windows to access and generating medical data (see: column 14, lines 8-16)." It is hard to 
understand how one could seriously assert that a server connected to client machines running 
applications such as Microsoft Windows equates to a tracking system updating a tracking record 
when the medical record data file is accessed - there is absolutely no mention of a tracking 
system, a tracking record, nor of the tracking record being updated. The construction adopted by 



015351.0001 DALLAS 608147 vl 



18 



the Examiner is incorrect, and therefore, the rejection should be reversed. 

Claim 5 depends from claim 1 and includes that the record client further comprises a 
remote data system, the remote data system generating medical record data, wherein the record 
client encapsulates the medical record data to prevent it from being modified. Claim 6 depends 
from claim 1 and includes that the record client system further comprises a detail encapsulation 
system receiving comment data and encapsulating the comment data to prevent it from being 
modified. Again, the Examiner construes encapsulation to be encryption, reading limitations out 
of claims 5 and 6 and denying patentees the right to be their own lexicographer. The 
construction adopted by the Examiner is incorrect, and therefore, the rejection should be 
reversed. 

Claim 7 depends from claim and includes that the record server further comprises a 
record storage system, the record storage system storing each version of the medical record data 
file received by the record server. The Examiner's construction equates this to "organizing and 
storing of patient medical records in which are made available for access by authorized 
personnel." This construction would not prevent the modification or deletion of a patient 
medical record that has been accessed by an authorized person, whereas claim 7 would do that 
by storing the version of the medical record that existed prior to it being accessed by the 
authorized person. In this manner, if an authorized person deleted a medical record, that fact 
could be determine by the change between the current version and the previous version, whereas 
the construction adopted by the Examiner would not. Thus, the Examiner's construction 
improperly reads limitations out of the claim and should be reversed. 

Claim 9 depends from claim 1 and includes a notification system transferring notification 
data to a party regarding the availability of medical record data. The Examiner construes this 
claim to mean "acknowledgement by the healthcare provider that a patient's record has been 
reviewed and adding to the medical record any necessary instructions or recommendations for 
treatment." This construction reads the limitation of "transferring notification data to a party 
regarding the availability of medical record data" out of the claim - if the transfer of the medical 
record itself constitutes the notification, then there is no need for transferring notification data. 
The construction adopted by the Examiner is incorrect, and therefore, the rejection should be 
reversed. 

Claim 12 depends from claim 10 and includes that assembling the medical record data 
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into the medical record data file further comprises storing a tracking record with the medical 
record data file. Again, the construction adopted by the Examiner fails to address the tracking 
record as being separate from the medical record data file and being used to track something. 
The Examiner construes claim 12 as an "electronic medical record system which stores and 
updates patient records upon a nurses or physician entry of information," citing to column 3, 
lines 9-16 and column 5, lines 29-40 of Evans. However, the nurses or physician's entry of 
information is made to the electronic medical record, not to the tracking record. The Examiner's 
construction improperly reads limitations out of the claim, and should be reversed. 

Claim 13 depends from claim 10 and includes generating notification data at the remote 
location. The Examiner's construction of claim 13 is incorrect for the same reasons previously 
discussed in regards to claim 9. 

Claim 14 depends from claim 10 and includes accessing the medical record data file at 
the remote location; and updating a tracking record to show that the medical record data file has 
been accessed at the remote location. The Examiner's construction of claim 14 is incorrect for 
the same reasons previously discussed in regards to claim 12. 

Claim 15 depends from claim 10 and includes receiving medical record data at the remote 
location; encapsulating the medical record data to prevent the medical record data from being 
modified; and updating the medical record data file to include the medical record data. The 
Examiner's construction of claim 15 is incorrect for the same reasons previously discussed in 
regards to claim 1. 

Claim 32 depends from claim 1 and includes that the medical record client operates in 
unattended mode, so as to allow the medical record data file to be received without user input. 
The Examiner's construction of claim 32 is incorrect for the same reasons previously discussed 
in regards to claim 25. 

In summary, the Examiner's construction of claims 1-15, 23, and 29-33 fails to allow the 
patentees to be their own lexicographer and reads limitations out of the claims, for the numerous 
reasons described above. The rejection of claims 1-15, 23, and 29-33 should therefore be 
reversed. 

7. Patentability of claims 16 through 22, 34, and 35 

Independent claims 16 and 20 and the associated dependent claims are drawn to a system 
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that can be used in one exemplary embodiment to allow prescription drugs to be dispensed at a 
remote location without requiring a licensed pharmacist to be present at that location. Under 
current laws, a licensed pharmacist must supervise the dispensing of prescription drugs. While 
mail or delivery services can then be used, there are many locations such as nursing homes 
where large numbers of identical prescriptions are typically dispensed. In these locations, the 
prior art would require the prescription data for each such prescription to be transmitted from a 
physician at the location to a pharmacist, and for the pharmacist to individually supervise the 
packaging and delivery of each prescription package. Claims 16 and 20 and the claims that 
depend from them provide a system whereby a pharmacist can supervise the creation of a large 
number of such packages, which can then be transmitted to a remote location and dispensed from 
that remote location as soon as the prescription is ordered by the physician and remotely verified 
by the pharmacist. The Examiner's construction of claims 16 and 20 and the claims that depend 
from them reads limitations out of the claims to yield a system that would require a licensed 
pharmacist to receive the prescription, prepare the package, and then supervise the delivery of 
each package to each patient. 

Claim 16 includes a "system for distributing medical supplies comprising: a record server 
receiving package data; a record client coupled to the record server, the record client receiving 
the package data from the record server and verification data; and wherein the record server 
receives the verification data from the record client and correlates the verification data to the 
package data." The Examiner construed claim 16 to be that disclosed by the combination of 
Evans at column 14, lines 8-16 and Portwood at the abstract, column 3 lines 43-49, and column 7 
lines 35-37, noting that Portwood discloses "a server computer communicating with other 
prescriber computer to transfer prescription data to the server for validation, certification, and 
distribution," and further asserting that "prescriptions are a form of 'medical supplies.'" The 
Examiner admitted that Evan fails to disclose the claim element of receiving package data from 
the record server with verification data and correlating the verification data to the package data, 
but alleged that the cited sections of Portwood disclose those elements. 

As previously discussed, the cited sections of Portwood disclose a prescriber computer 
station B that provides prescription information for a patient, and a prescription distribution 
company, such as a pharmacy or drug wholesale company. As disclosed at column 6, line 66 to 
column 7 line 3 of Portwood, the paths shown in Figure 2 of Portwood show "a preferred use of 
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the server computer station A to obtain a preferred flow of data, reports, and messages amongst 
the physician, the prescription distribution service organization, the patient, and the prescription 
payer. The various channels of information flow as described below as indicated by the 
information flow numbers in FIG. 2." (Emphasis added). In this regard, it appears that the 
Examiner may have confused "prescription data" with the package of prescription drugs that are 
assembled based on the prescription data, as both are loosely referred to as the "prescription" in 
Portwood. However, it is indisputable that Portwood fails to disclose a sealed package. 

The Examiner's construction of the claim, based on the disclosed portions of Evans and 
Portwood, is therefore incorrect, because it reads limitations (such as a sealed package) out of the 
claim. Claim 16 includes "a record server receiving package data." Portwood clearly states that 
information only flows on the paths shown in Figure 2 of Portwood, and described at column 7, 
lines 6-62 of Portwood. Thus, no package (and therefore, no package data) is created until the 
prescription data reaches the prescription distribution service. It therefore follows that "a record 
client coupled to the record server, the record client receiving the package data from the record 
server and verification data" is missing from Portwood - neither the prescriber or the payor 
would receive the prescription package from the prescription distribution service, which leaves 
only the patient. Data path 5 to the patient is only generated before the prescription package is 
created by the prescription distribution service, and pertains to messages that are scheduled to be 
sent to the patient regarding "general information, prescription history, and prescription 
calendar" - not verification data that is received by the record server and correlated to the 
package data." Data path 8 is only the response to these messages, and does not include 
verification data that is correlated to package data. The Examiner's construction of the claim 
reads out the claim limitations that pertain to the use of verification data to verify that the 
package data has been properly dispensed to the correct patient, and should be reversed. 

Claim 17 depends from claim 16 and includes an inventory tracking system receiving the 
verification data and incrementing order data. Neither Portwood nor Evans disclose such a 
system, which can be used to determine when a new batch of sealed prescription packages needs 
to be created and sent to a remote location such as a nursing home. Claim 18 depends from 
claim 16 and includes a record encapsulation system receiving the verification data and 
encapsulating the verification data in a medical record data file. The Examiner again construes 
encapsulation to be the point-to-point encryption disclosed by McGauley, which improperly fails 
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to allow the applicants to be their own lexicographer and reads limitations out of the claim. 
Claim 19 depends from claim 16 and includes a remote data system generating counseling data 
and transmitting the counseling data to the record server. Counseling from a licensed pharmacist 
is required by law where a prescription drug is being dispensed to a patient for the first time. 
The Examiner's construction of claim 19 as being that which is disclosed at Evans, column 2, 
lines 45-58 would require an authorized healthcare provider to be physically present at the 
remote system, and thus reads limitations out of the claim. The construction of these claims 
adopted by the Examiner is incorrect and should be reversed. 

The Examiner's construction of claims 20-22 likewise reads limitations out of the claims. 
In regards to the element of "storing package data corresponding to a sealed package," the 
Examiner construes this to be disclosed by Portwood, column 2, lines 60-66, which states "a 
system to facilitate compliance with a prescribed medical regimen is provided, which comprises 
a computer system having a data storage unit containing stored pharmaceutical data, a central 
processing unit (CPU) programmed and operatively connected to the data storage unit to further 
store in the data storage unit patient data and patient prescription data." There is no mention of a 
sealed package at all in the cited section of Portwood, nor anywhere else in Portwood. Portwood 
does not address one problem solved by the invention, namely, that a licensed pharmacist must 
be able to verify that prescription drugs have been dispensed to the correct patient. The prior art 
requires the licensed pharmacist to travel to patients that are unable to travel to the pharmacist, 
such as patients in nursing homes, whereas the invention allows the pharmacist to receive 
suitable verification data to confirm that the correct prescription drug has been provided to the 
correct patient. Nothing in Portwood suggests that prescriptions are dispensed in any manner 
other than using the process required by law, namely, of having a licensed pharmacist visually 
verify receipt of the prescription drug to the patient identified by the prescription received from 
the doctor. 

In regards to the element of "transmitting the sealed package to a remote site" of claim 
20, the Examiner construes this to be disclosed by the abstract and column 5, lines 7-10 of 
Portwood. The abstract states that a prescription drug service is notified to deliver prescribed 
drugs to the patient - again, not only failing to mention anything about a sealed package, but also 
failing to disclose anything other than the traditional method of using a licensed pharmacist to 
dispense the prescribed drugs. Column 5, lines 7-10 likewise only refers to a prescription 
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distribution system D that enables quicker delivery, failing to mention anything about sealed 
packages and inferring nothing other than the process required by law that a licensed pharmacist 
must dispense prescription drugs directly to the patient, such as in person, by mailing it to that 
person's address, or by delivering it to that person's address. 

In regards to "authorizing release of the package if the stored package data matches the 
received package data," the Examiner construes this to be disclosed by column 3, lines 36-41 of 
Portwood, which state that "the CPU is further programmed to generate a prescription delivery 
message, and wherein the system further comprises a message receiving unit operatively 
connected to the CPU to receive the prescription delivery message." The cited section of 
Portwood utterly fails to mention anything about authorizing release of a package or determining 
whether stored package data matches received package data. Furthermore, it appears that the 
Examiner is again confusing the prescription data with the prescription package, as the only 
subsequent mention of this "prescription delivery message" other than the cited section from the 
Summary of the Invention section of Portwood occurs at column 18, lines 34 through 46, which 
refer to the transmission of prescription data to the prescription delivery system D, where a 
licensed pharmacist must assemble a package containing the prescribed drug and dispense the 
prescribed drug to the patient identified by the prescription data. Again, the Examiner's 
construction of the claim reads out the limitations of determining whether the stored package 
data matches the received package data, and authorizing release of the package if it does. 

In regards to the element of "receiving the package data from the remote site," the 
Examiner construes this to be disclosed by Evans, column 2, lines 45-47 (which refers to 
providing instant access to a patient's electronic medical record by authorized healthcare 
providers) and column 10, lines 18-23 (which refers to receiving patient data from external 
sources). Evans, like Portwood, utterly fails to disclose sealed packages, storing package data 
corresponding to the sealed package, transmitting the sealed package to a remote site, and 
authorizing release of the package if the stored package data matches the received package data. 
The cited sections of Evans require authorized healthcare providers to be present at any location 
where the patient's electronic medical record is accessed. The Examiner's construction thus 
reads elements out of the claim that allow the licensed pharmacist to authorize release of 
prescribed drugs at a remote site without being present at the remote site. 

Claim 21 depends from claim 20 and includes counseling a patient if the patient has not 
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received the medical supplies before and generating counseling data. Again, the Examiner's 
construction would require a licensed pharmacist to be present to provide the counseling, and 
reads elements out of the claim that would allow the licensed pharmacist to verify that the correct 
counseling data has been provided from a remote location. Claim 22 also depends from claim 20 
and includes incrementing order data after the package is released. The Examiner's construction 
reads on the prior art, which requires a pharmacist to prepare each package after receiving the 
prescription data, and reads elements out of the claim that allow a number of packages 
containing predetermined dosages of prescription to be created and distributed to patients at 
locations where a licensed pharmacist is not present. 

Claim 34 depends from claim 16 and includes a data reader that reads the verification 
data from the package. The Examiner, using nothing more than the claims as a blueprint, 
construes claim 34 to be the same as Chudy, column 14, lines 54-63, and figure 25, items 119 
and 125, stating that one of ordinary skill in the art would have combined Chudy with Evans and 
Portwood to yield the invention of claim 34. As previously discussed, system 200 of Chudy 
shows a large assembly-line that is used to dispense the bulk medications from a plurality of bulk r- 
storage tablet cassettes 20 using a machine-readable code, which would necessarily require a 
licensed pharmacist to be present. The data reader of claim 34 reads verification data from a 
package at the point where it is dispensed - why would anyone go through the process of 
receiving package data at a record server; receiving the package data from the record server at a 
record client with verification data, and receiving the verification data from the record client at 
the record server and correlating the verification data to the package data if there was a licensed * 
pharmacist operating system 200 of Chudy at the location of the record client? It is clear that the 
Examiner performed a simple search for the term "data reader" in conjunction with "medication" 
or some other similar terms, using the claim as a guide, to find a reference that could be 
combined with Evans and Portwood, because there would be no motivation to try and use the 
data reader in a complex assembly line such as Chudy in a remote location to dispense packages 
that were already assembled by a licensed pharmacist. The Examiner's construction of this 
claim is incorrect for the reasons previously discussed in regards to claim 1 6, not to mention that 
the Examiner used the claim as a blueprint to hunt for a reference to combine with Evans and 
Portwood so as to provide the missing element. The rejection of this claim should be reversed. 

Claim 35 depends from claim 16 and includes an image data capture device that 
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generates image data, and the verification data includes the image data. Again, the Examiner's 
construction of this claim would require a licensed pharmacist to be present, and is incorrect and 
should be reversed because it reads limitations out of the claim. 



8. Patentability of claims 2, 11, 23, 31, and 33 

One of the problems previously noted with electronic medical record data is that a 

practitioner can mistakenly obtain the file for another patient, by either misspelling the patient's 

name, entering the wrong social security number, or by otherwise making errors. Claim 2 

depends from claim 1 and includes "a sync system verifying that the record client has received a 

sync file before transferring the medical record data file." Again, the term "sync file" is not a 

term of art, and the patentees should be allowed to be their own lexicographers. One exemplary 

embodiment of a sync file is defined in the specification at paragraph [0023]: 

In one exemplary embodiment, sync system 108 can transmit the 
entire medical record data file for a patient to record client 104a or 
104b, such that record client 104a or 104b stores the latest version 
of the entire medical record data file regardless of whether any 
version of that file exists on record client 104a or 104b. In another 
exemplary embodiment, sync system 108 can first determine 
which medical record data file or files a record client 104a or 104b 
has for a patient, and can then transmit only files or portions of 
files that have been changed, new files, or other suitable files. In 
this manner, sync system 108 ensures that the medical record data 
files stored on record client 104a and 104b are the most recent 
medical files, and further that sufficient files exist to particularly 
identify any patient, so as to prevent inadvertent misdiagnosis, 
misplacement or misfiling of medical record data files, or other 
problems. 

The Examiner construes claim 2 as follows: "This feature is met by the electronic 
medical record system including web servers (406, Fig. 24) that allow patient data to be transfer 
between external source as well as updating the patient record obviously suggesting that the 
comparing and checking of medical data take place to verify that an up-to-date medical record is 
available." However, web servers do not verify that sync data has been received before 
transferring file data. As previously described, the patient record 1 1 1 of Evans is transferred 
from the patient data repository 102 to a point of care system 100, but Evans does not disclose 
verifying that the record client has received sync data before transferring the patient record 111. 
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Thus, if two patients had the same name, the wrong file could easily be transferred without 
detection. Likewise, Evans does not store the patient record 111 at the remote system, but 
returns it as patient record 119 to patient data repository 102. The construction of claim 2 
adopted by the Examiner thus reads limitations out of the claim and does not allow the patentees 
to be their own lexicographers, and should be reversed. 

Claim 11 depends from claim 10 and includes that transferring the medical record data 
file to the remote location further comprises transferring a sync file to the remote location. The 
construction of claim 1 1 adopted by the Examiner reads limitations out of the claim and does not 
allow the patentees to be their own lexicographers for the reasons discussed in regards to claim 
2, and should be reversed. 

Claim 23 includes a record server having an encapsulated medical record data file, the 
encapsulated medical record data file having medical record data that can be viewed but which 
cannot be modified; a record client coupled to the record server, the record client receiving the 
encapsulated medical record data file; a sync system verifying that the record client has received 
sync data before transferring the encapsulated medical record data file; the record server further 
comprising a tracking system updating a tracking record when the encapsulated medical record 
data file is transferred; the record client further comprising a tracking system updating a tracking 
record when the encapsulated medical record data file is accessed; the record client further 
comprising a detail encapsulation system receiving comment data, encapsulating the comment 
data to prevent it from being modified, and storing the encapsulated comment data as part of the 
encapsulated medical record data file; and wherein the record client operates in unattended mode 
such that the encapsulated medical record data file can be received without an operator present. 
The construction of claim 23 adopted by the Examiner reads limitations out of the claim and 
does not allow the patentees to be their own lexicographers for the reasons discussed in regards 
to the previous claims, and should be reversed. 

Claim 31 depends from claim 2 and includes that the sync file is a patient file. 
Claim 33 depends from claim 1 1 and includes that transferring the sync file comprises creating a 
patient folder. The construction of claims 31 and 33 adopted by the Examiner reads limitations 
out of the claim and does not allow the patentees to be their own lexicographers for the reasons 
discussed in regards to claim 2, and should be reversed. 
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9. Summary 

For the reasons set forth above, Appellant submits that the Examiner's construction of the 
claims is improper on the grounds that it reads elements out of the claims and that it does not 
allow the applicants to be their own lexicographers, and that Appellant's properly construed 
claimed invention is indeed novel and unobvious over the applied references and the art of 
record. 

Accordingly, the Examinees rejections must be REVERSED , and claims 1-35 must be 
allowed. 
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IX. APPENDIX OF CLAIMS (37 C.F.R. § 1.192(c)(9)) 
The text of the claims involved in the appeal are as follows: 

1 . A system for transferring electronic medical files comprising: 

a record server having a medical record data file, the medical record data file having 
medical record data; 

a record client coupled to the record server, the record client receiving the medical record 
data file; and 

wherein the medical record data is encapsulated to prevent modification of the medical 
record data. 

2. The system of claim 1 wherein the record server further comprises a sync system 
verifying that the record client has received a sync file before transferring the medical record 
data file. 

3. The system of claim 1 wherein the record server further comprises a tracking 
system updating a tracking record when the medical record data file is transferred. 

4. The system of claim 1 wherein the record client further comprises a tracking . 
system updating a tracking record when the medical record data file is accessed. 

5. The system of claim 1 wherein the record client further comprises a remote data 
system, the remote data system generating medical record data, wherein the record client 
encapsulates the medical record data to prevent it from being modified. 

6. The system of claim 1 wherein the record client system further comprises a detail 
encapsulation system receiving comment data and encapsulating the comment data to prevent it 
from being modified. 

7. The system of claim 1 wherein the record server further comprises a record 
storage system, the record storage system storing each version of the medical record data file 
received by the record server. 

8. The system of claim 1 wherein the record server further comprises an excerpt 
transfer system, the excerpt transfer system receiving medical record excerpt data and 
transferring it to a predetermined recipient. 

9. The system of claim 1 further comprising a notification system transferring 
notification data to a party regarding the availability of medical record data. 

10. A method for transferring electronic medical files comprising: 
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encapsulating medical record data to prevent it from being modified; 
assembling the medical record data into a medical record data file; 
receiving a request to transfer the medical record data file; and 
transferring the medical record data file to a remote location. 

11. The method of claim 10 wherein transferring the medical record data file to the 
remote location further comprises transferring a sync file to the remote location. 

12. The method of claim 10 wherein assembling the medical record data into the 
medical record data file further comprises storing a tracking record with the medical record data 
file. 

13. The method of claim 10 further comprising generating notification data at the 
remote location. 

14. The method of claim 10 further comprising; 
accessing the medical record data file at the remote location; and 

updating a tracking record to show that the medical record data file has been accessed at 
the remote location. 

15. The method of claim 10 further comprising: 
receiving medical record data at the remote location; 

encapsulating the medical record data to prevent the medical record data from being 
modified; and 

updating the medical record data file to include the medical record data. 

16. A system for distributing medical supplies comprising: 
a record server receiving package data; 

a record client coupled to the record server, the record client receiving the package data 
from the record server and verification data; and 

wherein the record server receives the verification data from the record client and 
correlates the verification data to the package data. 

17. The system of claim 16 further comprising an inventory tracking system receiving 
the verification data and incrementing order data. 

18. The system of claim 16 wherein the record server further comprises a record 
encapsulation system receiving the verification data and encapsulating the verification data in a 
medical record data file. 
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19. The system of claim 16 wherein the record client further comprises a remote data 
system, the remote data system generating counseling data and transmitting the counseling data 
to the record server. 

20. A method for distributing medical supplies comprising: 
storing package data corresponding to a sealed package; 
transmitting the sealed package to a remote site; 

receiving the package data from the remote site; and 

authorizing release of the package if the stored package data matches the received 
package data. 

21. The system of claim 20 wherein receiving the package data from the remote site 
further comprises: 

counseling a patient if the patient has not received the medical supplies before; and 
generating counseling data. 

22. The method of claim 20 further comprising incrementing order data after the 
package is released. 

23. A system for transferring electronic medical files comprising: 

a record server having an encapsulated medical record data file, the encapsulated medical 
record data file having medical record data that can be viewed but which cannot be modified; 

a record client coupled to the record server, the record client receiving the encapsulated 
medical record data file; 

a sync system verifying that the record client has received sync data before transferring 
the encapsulated medical record data file; 

the record server further comprising a tracking system updating a tracking record when 
the encapsulated medical record data file is transferred; 

the record client further comprising a tracking system updating a tracking record when 
the encapsulated medical record data file is accessed; 

the record client further comprising a detail encapsulation system receiving comment 
data, encapsulating the comment data to prevent it from being modified, and storing the 
encapsulated comment data as part of the encapsulated medical record data file; and 

wherein the record client operates in unattended mode such that the encapsulated medical 
record data file can be received without an operator present. 
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24. A method for transferring electronic medical data comprising: 

determining whether a patient file having a predetermined patient data structure exists for 
a patient on a remote system; 

transferring the electronic medical data to the patient file if it is determined that it exists; 

creating the patient file with the predetermined patient data structure on the remote 
system if it is determined that the patient file does not exist on the remote system; and 

transferring the electronic medical data to the newly created patient file on the remote 
system if it is determined that the patient file does not exist on the remote system. 

25. The method of claim 24 wherein the remote system operates in an unattended 
mode that allows the electronic medical data to be transferred without operator input. 

26. The method of claim 25 wherein the remote system receives electronic medical 
data for two or more users in unattended mode, and each user must enter a user-specific access 
ID to access the electronic medical data for that user. 

27. A method for transferring electronic medical record data comprising: 
extracting an excerpt of the electronic medical record data from an electronic medical 

record data file at a first location; 

transmitting the excerpt to a remote location; 
receiving comment data associated with the excerpt; 
transmitting the comment data to the first location. 

28. The method of claim 27 wherein extracting an excerpt of the electronic medical 
record data from the electronic medical record data file comprises removing user-readable 
patient identifying data. 

29 A method for transferring electronic medical record data comprising: 
encapsulating an electronic medical record file so as to allow it to be viewed and to 
prevent it from being modified; 

encrypting the encapsulated electronic medical record file; 

transmitting the encrypted encapsulated electronic medical record file to a remote 
location; 

decrypting the encrypted encapsulated electronic medical record file at the remote 
location; and 

generating a user-readable display using the encapsulated electronic medical record file. 
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30. The method of claim 29 wherein the electronic medical record file is an image 
data file. 

3 1 . The system of claim 2 wherein the sync file is a patient file. 

32. The system of claim 1 wherein the medical record client operates in unattended 
mode, so as to allow the medical record data file to be received without user input. 

33. The method of claim 11 wherein transferring the sync file comprises creating a 
patient folder. 

34. The system of claim 16 wherein the record client further comprises a data reader 
that reads the verification data from the package. 

35. The system of claim 16 wherein the record client further comprises an image data 
capture device that generates image data, and the verification data includes the image data. 
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ABSTRACT 



A medical records system that creates and maintains all 
patient data electronically. The system captures patient data, 
such as patient complaints, lab orders, medications, 
diagnoses, and procedures, at its source at the time of entry 
using a graphical user interface having touch screens. Using 
pen-based portable computers with wireless connections to 
a computer network, authorized healthcare providers can 
access, analyze, update and electronically annotate patient 
data even while other providers are using the same patient 
record. The system likewise permits instant, sophisticated 
analysis of patient data to identify relationships among the 
data considered. Moreover, the system includes the capabil- 
ity to access reference databases for consultation regarding 
allergies, medication interactions and practice guidelines. 
The system also includes the capability to incorporate legacy 
data, such as paper files and mainframe data, for a patient. 
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ELECTRONIC MEDICAL RECORDS abnormal laboratory test results, prescribed medications to 

SYSTEM address the abnormality, and specific treatments adminis- 
tered by the physician, may not be apparent within a patient 

FIELD OF THE INVENTION file. 

The present invention relates to electronic healthcare 5 In the current environment, specific patient data is difBcult 

systems, and more particularly, to a system for storage and t0 access when needed for analysis. The creation of patient 

retrieval of electronic medical records in a computer data in remote locations exacerbates this problem. In 

environment, such as a local or wide area network including addition, the wide variety of data formats for patient data 

portable computers. hinders electronic processing and maintenance of patient 

10 files. Moreover, the use of a patient's file by one healthcare 

DESCRIPTION OF RELATED TECHNOLOGY provider can preclude its simultaneous use by another 

lT u . . , , . ■ .i healthcare provider. Ongoing consolidation of healthcare 

Healthcare providers, such as physicians, create large r. . , mf - * • 

, r . • r *• » ■ .1 c *u • providers into large health maintenance organizations 

volumes of patient information during the course oi their /i, w ^ \ j *• , . 4 . x 

, - * u i.u *• •!•*• u u * i i* (HMOs) and preferred provider organizations (PPOs) create 

busmess at healthcare iaciuties, such as hospitals, clinics, : • . ? j r \ j , • t 

. . . . . , ~ „ i u " issues in the transfer and maintenance of patient data in large 

laboratories and medical offices. For example, when a , • »_ • . i • ttj*_ 

...... . • * c l i . . enterprises having numerous remote locations. Under these 

patient visits a physician tor the first time, the physician r . , . ,.„- w 

r „ . .ci ■ i j- *u .» j- circumstances, healthcare providers have difficulty provid- 

gene rally creates a patient nle mcludmg the patient s medi- . ™. . / 4 . r .i* . 

i . . ' * . . . j- 7- • a ing effective treatment for their patients, 

cal history, current treatments, medications, insu ranee and ° r 

other pertinent information. This file generally includes the 20 SUMMARY OF THE INVENTION 
results of patient visits, including laboratory test results, the 

physician's diagnosis, medications prescribed and treat- The electronic medical record (EMR) system of the 

ments administered. During the course of the patient present invention automates and simplifies existing methods 

relationship, the physician supplements the file to update the of patient chart creation, maintenance and retrieval. In 

patient's medical history. When the physician refers a ^ contrast to other systems, the present invention creates and 

patient for treatment, tests or consultation, the referred maintains all patient data electronically and thus can elimi- 

physician, hospital, clinic or laboratory typically creates and nate or supplement creating and maintaining of physical data 

updates similar files for the patient. These files may also records. The EMR system finishes healthcare providers with 

include the patient's billing, payment and scheduling an intuitive, easy-to-use, icon-based interface that enables 

records. 30 them to capture and analyze patient data quickly and effi- 

Healthcare providers can use electronic data processing to ciently. Using the present invention, healthcare providers 

automate the creation, use and maintenance of their patient enter patient data immediately at the point of care. Thus, the 

records. For example, in U.S. Pat. No. 5,277,188, assigned £ MR system captures each piece of data at its source at the 

to New England Medical Center Hospitals, Inc., Selker time of entry to provide a complete audit trail for all patient 

discloses a clinical information reporting system having an 35 da ta. In this manner, the EMR system transforms a patient 

electronic database including electrocardiograph related cna rt from a static record of a few clinical interactions into 

patient data. Similarly, Schneiderman discloses a computer a dynamic, real-time comprehensive record linked to an 

system for recording electrocardiograph and/or chest x-ray enterprise-wide clinical database. In addition, the EMR 

test results for a database of patients in U.S. Pat. No. system of the present invention includes the capability to 

5,099,424. In U.S. Pat. No. 4,315,309, Coli discloses a 40 manage a wide variety of patient data formats, including 

patient report generating system for receiving, storing and patient data from external sources, such as laboratories and 

reporting medical test data for a patient population. Mitchell, pharmacies. The EMR system can also incorporate a 

in U.S. Pat. No. 3,872,448, likewise discloses a system for patient's legacy data, such as a paper chart, into the patient 

automatically handling and processing hospital data, such as record as well as legacy data from mainframe computers, 

patient information and pathological test information using 45 The present invention likewise provides instant access to 

a central processing apparatus. In U.S. Pat. No. 5,065,315, a patient's electronic medical record by authorized health- 

Garcia discloses a computerized scheduling and reporting care providers from any geographical location. Thus, the 

system for managing information pertinent to a patient's EMR system enables authorized healthcare providers to 

stay in the hospital. However, these electronic data process- access and update patient files using wireless pen-based 

ing systems can not handle patient data in the wide variety 50 personal computers. To enable complete replacement of 

of data formats typically produced by healthcare providers, physical records, the present invention permits healthcare 

such as physicians, laboratories, clinics and hospitals. providers, such as physicians or nurse practitioners, to 

Physicians often use paper based forms and charts to electronically annotate patient data. Thus, a healthcare pro- 
document their observations and diagnosis. Laboratories vider can acknowledge reviewing patient data, provide 
also produce patient data in numerous forms, from x-ray and 55 instructions, such as prescriptions for medication to admin- 
magnetic resonance images to blood test concentrations and ister to a patient, and approve recommendations for treat- 
electrocardiograph data. Clinics and hospitals may use a ment by other providers, all by electronically annotating a 
combination of paper based charts and electronic data for patient's record. In addition, authorized healthcare providers 
patient records. The same patient data may exist in remote can access a record while other providers use the same 
patient files located at clinics, hospitals, laboratories and 60 record allowing for real-time collaboration. The availability 
physicians'oflfices. Similarly, patient files at one healthcare of electronic data permits instant, sophisticated analysis of 
provider typically have different information than patient patient data. Moreover, the EMR system enables enhanced 
files at another healthcare provider. When in use, patient files analysis of patient data by providing access to reference 
are generally not available to other healthcare providers. In databases for diagnosis, procedures and medication, 
addition, at the time of creation, patient data is generally not 65 One aspect of the present invention includes a medical 
available for use by remotely located healthcare providers. records system, comprising a point of care system to capture 
Moreover, relationships among specific patient data, such as patient data at a point of care and a patient data repository, 
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in communication with the point of care system and with 
external systems, to store and organize the patient data for 
access by the point of care system. 

Another aspect of the present invention includes a medi- 
cal records system comprising a point of care system to 
capture data in a patient record at a point of care, wherein the 
patient record includes a patient identifier and at least one 
data structure including the patient identifier and the data. 

Yet another aspect of the present invention includes a 
medical records system comprising a point of care system to 
capture data at a point of care and a patient data repository, 
in communication with the point of care system and with 
external systems to store and organize the data in a patient 
record for access by the point of care system, wherein the 
patient record includes a patient identifier and at least one 
data structure including the patient identifier and the data. 

In addition, another aspect of the present invention 
includes a method of using an electronic medical records 
system, comprising the steps of capturing patient data elec- 
tronically at the point of care, organizing the patient data so 
as to form a patient record, filing the patient record, and 
retrieving the patient record to access the patient data for use 
in the care of a patient. 

Yet another aspect of the present invention includes a 
method of retrieving patient data in an electronic medical 
records system having a patient data repository, comprising 
the steps of obtaining a patient identifier, locating a patient 
record corresponding to the patient identifier in the patient 
data repository, and determining the location of the patient 
data within the patient record. 

Another aspect of the present invention includes a method 
of managing a patient data repository having a cache and a 
data archive, comprising the steps of monitoring a status of 
data within the cache, and moving the data to the data 
archive when the status exceeds a threshold. 

Still another aspect of the present invention includes a 
method of communicating with an external source having an 
interface to an electronic medical records system, compris- 
ing the steps of finding an interface for the external source, 
connecting to the external source using the interface, and 
converting patient data for transfer between the external 
source and the electronic medical records system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating the electronic 
medical record (EMR) system architecture of the present 
invention. 

FIG. 2 is a flowchart illustrating the process flow of the 
EMR system of the present invention. 

FIG. 3 shows an example of a graphical user interface of 
the EMR system useful for the scheduling of a patient 
appointment as shown in FIG. 2. ' 

FIG. 4 is a block diagram illustrating the structure of the 
point of care system of FIG. 1. 

FIG. 5 shows an example of a graphical user interface of 
the point of care system of FIG. 4. 

FIG. 6 shows an example of a new form window of the 
point of care system of FIG. 4. 

FIG. 7 shows an example of an annotate window of the 
point of care system of FIG. 4. 

FIG. 8 shows an example of a viewer window displaying 
an image of patient data of the point of care system of FIG. 
4. 

FIG. 9 is a block diagram illustrating the structure of a 
medication data capture in the point of care system of FIG. 
4. 



24,074 

4 

FIG. 10 is a block diagram illustrating the structure of a 
practice guideline in the point of care system of FIG. 4. 

FIG. 11 is a block diagram illustrating the structure of the 
medication data capture and the practice guideline in the 
5 point of care system of FIG. 4. 

FIG. 12 is a block diagram illustrating the structure of the 
patient data repository of FIG. 1. 

FIG. 13 is a block diagram illustrating the structure of a 
10 patient record within the patient data repository of FIG. 12. 
FIG. 14 is an example of the patient record of FIG. 13. 
FIG. 15a is a flowchart illustrating the process flow of the 
patient data repository of FIG. 12. 
FIG. 156 is a flowchart illustrating the process for a 
15 transfer of data from a cache to a data archive in the patient 
data repository of FIG. 12. 

FIG. 16 is a block diagram illustrating the structure of the 
data interface of FIG. 12. 
2{) FIG. 17a is a flowchart illustrating the process flow of the 
data interface of FIG. 16 when receiving patient data from 
an external source. 

FIG. 17b is a flowchart illustrating the process flow of the 
data interface of FIG. 16 when transmitting patient data to 
25 an external source. 

FIG. 18 is a block diagram illustrating the structure of the 
reference database of FIG. 1. 

FIG. 19 shows an example of a graphical user interface of 
the point of care system of FIG. 4 having a reference access 
30 button and a medication manager button. 

FIG. 20 shows an example of a graphical user interface 
for the diagnosis module and the procedure module of the 
reference database of FIG. 18. 
35 FIG. 21 shows an example of a graphical user interface 
for the medication manager of the reference database of FIG. 
18. 

FIG. 22 shows an example of a medication interaction 
window of the medication manager of FIG. 21. 
40 FI G . 23 is a block diagram illustrating the structure of the 
legacy data system of FIG. 1. 

FIG. 24 is an example of a typical configuration for the 
electronic medical records system of the present invention. 

45 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 

The following detailed description of the preferred 
embodiments presents a description of certain specific 
5Q embodiments to assist in understanding the claims. 
However, one may practice the present invention in a 
multitude of different embodiments as defined and covered 
by the claims. 

For convenience, the description comprises three sec- 
55 lions: EMR System Architecture and Overview, EMR Sys- 
tem Configurations and Summary. The first section provides 
an overview of the EMR system architecture, the following 
section describes EMR system applications and preferred 
embodiments for practicing the EMR system of the present 
50 invention, and the remaining section summarizes advanta- 
geous features of the present invention. 

I. EMR System Architecture and Overview 

FIG. 1 illustrates the architecture of the EMR system. 
65 Healthcare providers, such as physicians, at hospitals, labo- 
ratories and clinics, generally capture and access patient data 
using a point of care system 100 that communicates with a 
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patient data repository 102. Patient data, such as vital signs, 
x-ray images and laboratory results, resides in the patient 
data repository 102. The patient data repository 102 also 
communicates with external sources to obtain patient data, 
such as laboratory test results and x-ray images, and to 
transfer patient information, such as prescriptions for 
medication, from the EMR system to other healthcare pro- 
viders. The point of care system 100 captures patient data in 
real-time at the point of care, that is, where healthcare 
providers interact with their patients. For example, physi- 
cians can use a point of care system 100 to enter, access, 
process, analyze and annotate data from patient records in 
real-time at the point of care. Thus, using the point of care 
system 100, a physician, who has many patients in a 
hospital, can visit each patient in their room, access their 
electronic patient record there, enter results of the current 
examination, evaluate their medical history, electronically 
annotate their x-rays images and prescribe medications and 
treatments instantaneously as the point of care system 100 
captures and organizes patient data into the patient record 
stored in the patient data repository 102. The point of care 
system 100 may likewise communicate with a reference 
database 104 to assist a healthcare provider in making 
diagnoses, prescribing medications and administering treat- 
ments. Moreover, the patient data repository 102 may also 
communicate with a legacy data system 106 to access 
pertinent patient data in paper files and mainframe electronic 
databases. 

Referring now to FIG. 2, a flowchart illustrates the 
operation of the EMR system. For example, a patient having 
a complaint contacts a healthcare provider 110, such as a 
physician, to schedule an appointment. The EMR system 
obtains the patient record 111 from the patient data reposi- 
tory 102 (FIG. 1) prior to the scheduled appointment. The 
EMR system is also capable of handling patients on a 
walk-in basis by scheduling an appointment and requesting 
the patient *s record immediately thereafter. The EMR sys- 
tem updates the patient record 112 to include the complaint 
and other information pertinent to the appointment, such as 
insurance information. A healthcare provider, such as a 
physician, examines the patient 113 using the point of care 
system 100 (FIG. 1) to make a diagnosis and to treat the 
patient's condition. As determined at 114, if a diagnosis is 
not possible on the basis of this examination, the physician 
may need to obtain additional clinical data 115, such as 
laboratory tests and x-rays. When available, the physician 
uses the point of care system 100 (FIG. 1) to evaluate the 
results 116 and to examine the patient 113 again in light of 
the results. Upon making a diagnosis, the physician may 
need to prescribe medications 117 for the patient's condi- 
tion. Similarly, the physician may need to administer a 
treatment 118 to address the patient's condition. At the 
conclusion of the patient's visit, the EMR system files the 
patient's record 119 in the patient data repository 102 (FIG. 
1) for future reference. 

Id a preferred embodiment, the EMR system includes 
graphical user interfaces to access system functions. For 
example, as shown in FIG. 3, a chart puller window 120 
enables a healthcare provider to schedule a patient appoint- 
ment using its point and click interface. To schedule an 
appointment, a healthcare provider activates the select but- 
ton 121 with a pointing device, such as a mouse or electronic 
pen, to obtain a list of patients. The healthcare provider then 
scans the list to select the name of the appropriate patient 
using a pointing device. The EMR system places the name 
of the selected patient in the patient box 123. Similarly, the 
healthcare provider uses the up/down buttons 125 to select 
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an appointment date and an appointment time. An adjacent 
box, such as the date box 126, displays the selected date and 
time. Lastly, the healthcare provider enters a textual descrip- 
tion of the patient's complaint in a reason box 127. Note that 
the healthcare provider can review prior or future scheduled 
appointments by clicking on the appointments button 128. 
Similarly, the healthcare provider can track referrals by 
entering the identity of persons who referred this patient to 
their care in the referral box 129. 

) Referring now to FIG. 4, a block diagram illustrates the 
structure of the point of care system 100. The point of care 
system 100 includes the following modules: a patient data 
capture 140, a clinical data capture 142, progress notes 144 
and an encounter data capture 146. During a patient visit, the 

; healthcare provider (not shown) can enter, review and anno- 
tate patient information, such as family history, 
appointments, current medications and complaints, using the 
patient data capture 140. The healthcare provider can like- 
wise enter, review and annotate clinical data obtained during 

i the visit, such as body temperature and blood pressure, using 
the clinical data capture 142. Similarly, the healthcare pro- 
vider can enter laboratory data for patients with the clinical 
data capture 142. The clinical data capture 142 communi- 
cates with the patient data capture 140 to assist in identifying 

; needs for further clinical data. For example, a family history 
of high blood pressure may indicate a need to obtain the 
patient's blood pressure during the visit. The patient data 
capture 140 also communicates with the encounter data 
capture 146, where a healthcare provider can enter, review 

i and annotate data regarding diagnoses and procedures 
administered to the patient. Moreover, the healthcare pro- 
vider can use the progress notes 144 to summarize details of 
the patient's condition and to review the patient's progress 
over time. Thus, the progress notes 144 communicates with 
the patient data capture 140, the clinical data capture 142 
and the encounter data capture 146. 

Referring now to FIG. 5, in a preferred embodiment, the 
point of care system 100 (FIG. 1) includes a graphical user 
interface having a patient chart window 150 to capture 
patient information. The point of care system 100 presents a 
patient record graphically using a tabbed layout to organize 
patient data. The patient chart window 150 includes tabs for 
patient data 151, clinical data 152, encounter data 153 and 
progress notes 154. Pointing and clicking on a tab on the 
patient chart window 150 opens a folder window 155 where 
a healthcare provider can enter and review patient data 
within the folder. For example, to activate progress notes 
144 (FIG. 4), the healthcare provider selects the progress 
notes tab 154 to display a list of progress note data in the 
folder window 155. In a similar manner, to activate the 
patient data capture 140, the clinical data capture 142 or the 
encounter data capture 146, one selects the patient data tab 
151, the clinical data tab 142, or the encounter data tab 153, 
respectively. 

To enter patient data, the healthcare provider clicks on the 
scroll down button 156 to select a form from a list of 
available forms to enter patient data. This activates the new 
forms box 157. The provider then points and clicks on the 
new form button 158. For example, FIG. 6 shows a new 
form window 161 displaying the pediatric problem form 162 
selected by the healthcare provider using the scroll down 
button 156 (FIG. 5). The healthcare provider fills out the 
pediatric problem form 162 using an input device, such as a 
keyboard, a mouse or an electronic pen. For example, the 
provider uses a keyboard to enter text "6/7/96 Stomach 
Ache" 164 and an electronic pen to enter initials 166 for 
identification. When done with patient data entry, the pro- 
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vider exits the form using the File Menu 168 and the point the patient data capture 140 and with the progress note 144. 

of care system 100 returns the provider to the patient chart Similarly, the practice guideline 149 communicates with 

window 150 (FIG. 5). Referring back to FIG. 5, the new patient data capture 140, the clinical data capture 142, the 

form appears as the top entry of the list in the folder window encounter data capture 146 and the progress note 144. 

155. 5 However, the practice guideline 149 may now communicate 

Similarly, to annotate patient data, the healthcare provider with the medication data capture 148 to address situations 

first selects an item to annotate by pointing and clicking on where accepted practice guidelines require a healthcare 

the item in a list displayed in the folder window 155. The provider to prescribe and administer medications. In a 

provider then clicks on the annotate button 159 to open the preferred embodiment, the point of care system 100 includes 

item in an annotate window 170, as shown in FIG. 7. For ^ me g ra phic a l user interface illustrated in FIG. 5. Referring 

example, the annotate window 170 of FIG. 7 displays a back to FIG. 5, the patient chart window 150 includes tabs 

blood test result 172. As before, the healthcare provider for medication data 191 and practice guidelines 193 that 

annotates the blood test result document 172 using an input activate the medication data capture 148 and the practice 

device, such as a keyboard, a mouse or an electronic pen. For guideline 149, respectively. Similarly, pressing the medica- 

example, the provider uses a keyboard to enter text "Out of l5 tion manager button 192 activates the medication data 

Range" 174 and an electronic pen to circle 176 the out of capture 148 and the practice guideline 149. A healthcare 

range result. When done with annotations, the provider exits provider can enter, review and annotate patient medication 

the form using the File Menu 178 and the point of care data and practice guideline data as described previously, 

system 100 returns the provider to the patient chart window Referring now to FIG. 12, a block diagram illustrates the 

150 (FIG. 5). Note that the point of care system 100 tracks 20 structure of the patient data repository 102. The patient data 

the review of patient data and identifies reviewed files with repository 102 includes a patient locator 200, a data manager 

a mark 160 in the folder window 155. By annotating patient 202 and a data interface 204. The patient locator 200 

data, a healthcare provider, such as a physician, can generates a unique patient identifier (PID) 221 (FIG. 14) for 

acknowledge reviewing patient data, provide instructions, each patient and creates and maintains a table having PIDs 

such as directions for additional tests and procedures or 25 for all patients who have data in the patient data repository 

prescriptions for medication to administer to the patient, and 102. All data records related to a patient 211, 212, 213, 214, 

approve recommendations for treatment by other healthcare 215, 216, 219 include and reference the patient's unique PID 

providers. Lastly, as shown in FIG. 8, a healthcare provider as shown in FIG. 13. 

uses the patient chart window 180 to view patient data. First, With reference to FIG. 13, upon creation of a patient 
the healthcare provider selects a view item 182 by either 30 record, the patient locator 200 creates a patient data structure 
pointing and clicking twice on the item in a list displayed in 210 having the PID and the patient's name. In a preferred 
the folder window 184 or by pointing at the item in the list embodiment, the patient data structure 210 includes pointers 
and pressing the view button 183. The double click opens a to data structures having data within a patient record cap- 
viewer window 185 to display the view item 182. For tured by the point of care system 100 and incorporated from 
example, the viewer window 185 of FIG. 8 displays an x-ray 35 external sources (e.g., a digital x-ray image file stored in a 
186. As before, the healthcare provider may annotate the raster pixel format). Thus, the patient data structure 210 
x-ray 186 with comments and observations by clicking on maintains a pointer to an interface files structure 211 having 
the annotate button 187. The healthcare provider may like- patient data transmitted from external sources. The patient 
wise close the viewer window 185 by clicking on the close data structure 210 likewise maintains pointers to a clinical 
button 189. 4Q data structure 212, a progress note structure 213 and an 
Certain additional structures in the point of care system encounter data structure 214. These data structures include 
100 (FIG. 1) will now be discussed with reference to FIGS. patient data captured by the clinical data capture 142, 
9, 10 and 11. Referring now to FIG. 9, an optional medica- progress notes 144 and encounter data capture 146, respec- 
tion data capture 148 supplements the structure of the point tively (FIG. 4). In another preferred embodiment, the patient 
of care system 100 of FIG. 4. A medication data capture 148 45 data structure 210 may include pointers to data structures 
allows a healthcare provider to monitor a patient's medica- having data generated by the reference database 104 and 
tions. The medication data capture 148 communicates with transferred by the legacy data system 106. Thus, the patient 
the patient data capture 140 to account for medications the data structure 210 may maintain pointers to a medication 
patient is currently taking. The medication data capture 148 data structure 215 and a guideline data structure 216. As 
similarly communicates with the progress notes 144, where 50 described above, the medication 215 and guideline 216 data 
a practitioner can monitor changes in a patient's condition structures include patient data captured by the medication 
resulting from medication therapies. Referring now to FIG. data capture 148 and the practice guideline 149, respec- 
10, an optional practice guideline 149 supplements the tively. In this embodiment, a reference data structure 217 
structure of the point of care system of FIG. 4. The practice may maintain pointers to the encounter data structure 214 
guideline 149 provides references for practitioners to consult 55 and to the medication data structure 215 for access to 
regarding courses of action to obtain a diagnosis and alter- reference information contained in a reference database 104. 
native treatments for various conditions. The practice guide- Lastly, the patient data structure 210 may maintain a pointer 
line 149 communicates with the patient data capture 140, the to a legacy files structure 219 having patient data transmitted 
clinical data capture 142 and the encounter data capture 146 from the legacy data system 106, such as an image of a 
to assist the practitioner in selecting the appropriate course 60 patient chart. 

of action. The practice guideline 149 likewise communicates FIG. 14 shows a logical view of a patient record 220 

with the progress notes 144 to provide a healthcare provider corresponding to the structure illustrated in FIG. 13. The 

with a historical context of the patient's condition and patient record 220 includes the PID generated by the patient 

alternative treatments already attempted. locator 200 (FIG. 12) in the patient data repository 102 (FIG. 

FIG. 11 shows a point of care system 100 having a 65 1). In addition, the patient record 220 includes patient data 

medication data capture 148 and a practice guideline 149. As in a variety of data types generated by healthcare providers, 

before, the medication data capture 148 communicates with Thus, the patient record includes text data 223, such as 
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electronic mail and word processing documents from other 
healthcare providers, image data 225, such as scanned 
physical documents, x-rays and CATSCANs, and audio data 
227, such as a physician's dictation and voice mail. Lastly, 
the patient record 220 has data tables 229, such as a 
physician's ICD9 diagnosis codes and CPT procedure 
codes. In view of the structure of a patient record 220, 
referring back to FIG. 12, the data manager 202 uses the PID 
to store and retrieve patient records. Moreover, the data 
interface 204 permits communication with external sources 
to obtain patient data, such as demographic data, laboratory 
test results and x-ray images, and to transfer patient 
information, such as prescriptions for medication, from the 
patient data repository 102 to external healthcare providers. 

With reference to FIG. 12, the patient data repository 102 
may optionally include a cache 206 for temporary storage of 
patient data and a data archive 208 for long term storage of 
patient data. In this embodiment, the data manager 202 
coordinates the transfer of patient data to and from a data 
archive 208 into a cache 206. For example, the data manager 
202 may identify patient records that a healthcare provider 
needs for appointments scheduled at a future time and then 
transfer these patient records from the data archive 208 into 
the cache 206 for quick access prior to the scheduled 
appointment. Similarly, the data manager 202 may purge 
from the cache 206 records of patients who have not had 
recent appointments and whose records are already 
archived. The data manager 202 likewise tracks the location 
and description of patient data within the data archive 208 by 
associating the file name of the patient data within a patient 
record 220 with the patient identifier 221. When possible, 
the data manager 202 will group data associated with a 
patient within the data archive 208 for rapid retrieval in a 
manner similar to files within a directory in an operating 
system. Thus, the data manager 202 assigns a directory to 
each patient identifier and then stores patient data within this 
directory, 

FIG. 15a illustrates the process flow for the patient data 
repository 102 (FIG. 1). For example, the point of care 
system 100 (FIG. 1) issues a request for patient data 250. 
With reference to FIGS. 15a and 12, the patient locator 200 
receives the request from the point of care system 100 and, 
at 251 attempts to find the PID for the record having the 
requested patient data. As determined at 252, if no PID is 
found, the patient locator 200 reports an error 253. At this 
point, the patient data repository 102 (FIG. 1) may recover 
from the error 253 by either restarting the process or by 
ending the process. Otherwise, the patient locator 200 com- 
municates the PID to the data manager 202. The data 
manager 202 locates the patient record using the PID at 254. 
As determined at 255, in a system without cache 206 and 
without a data archive 208, the data manager 202 delivers 
the requested data 256 to the point of care system 100. In a 
system having a cache 206 and a data archive 208, the data 
manager 202 determines at 257 if the requested data exists 
in the cache 206. If so, the data manager 202 delivers the 
requested data 256 to the requester from the cache 206. 
Otherwise, the data manager 202 first moves the data 258 
from the data archive 208 to the cache 206 and then delivers 
the requested data 254 to the requester from the cache 206. 

In addition, FIG. 15b t in conjunction with FIG. 12, 
illustrates the process for transferring data from a cache 206 
to a data archive 208. The data manager 202 monitors the 
contents of the cache 206. To improve the performance of 
the cache 206, the data manager 202 requests transfer 260 of 
data to the data archive 208 under certain conditions. For 
example, the data manager 202 may purge the cache 206 
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when data requested for storage in the cache would exceed 
its memory capacity. In this circumstance, the data manager 
202 first transfers to the data archive 208 signed files and 
then data files in chronological order, i.e., oldest files first. 
5 Similarly, a healthcare provider can specify a predetermined 
time, such as 3 calendar days, or other selected conditions 
for transfer to the data archive 208. As determined at 262, if 
the cache 206 does not have the data to transfer, the process 
ends as the data manager 202 ignores the request. As 

10 determined at 264, if the data in the cache 206 is not ready 
for transfer, the process ends and the data manager 202 
queues the request for the next transfer of data to the data 
archive 208. Data in the cache 206 is ready for transfer when 
a physician has reviewed and accepted it and when it has not 

3S been previously committed to the data archive 208. 
Otherwise, the data manager 202 transfers data from the 
cache 206 to the data archive 208 at 266. 

Referring now to FIG. 16, the data interface 204 of the 
patient data repository 102 includes an interface manager 

20 270, a data handler 272 and a communication interface 274. 
To transfer and receive patient data from external sources 
(not shown), the interface manager 270 communicates with 
a data handler 272 and a communication interface 274. In 
addition, the communication interface 274 communicates 

25 with the data handler 272 for conversion of received external 
patient data into formats recognized by the EMR system. 
The interface manager 270 creates and maintains an inter- 
face registry of data formats for external sources. Prior to 
data transfer or receipt by the EMR system, the interface 

30 manager 270 registers an interface for an external source. 
Upon registration of an interface, the interface manager 270 
can provide the appropriate conversion routines for the data 
handler 272 to use for transfer of data to and receipt of data 
from an external source. These conversions are well under- 

35 stood by the relevant technologist. 

FIGS. 17a and 17b illustrate the operation of the data 
interface 204 of the patient data repository 102 (FIG. 12). 
Referring now to FIG. 17a, the data manager 202 issues a 
request 280 for patient data from an external source. At 282, 

40 the interface manager 270 determines if the registry includes 
an interface for the external source, such as a laboratory or 
pharmacy. As determined at 282, if the registry includes an 
interface for the external source, the communication inter- 
face 274 connects to the external source 284 to receive 

45 patient data. The data handler 272 retrieves the appropriate 
conversion routine for the external source to convert data 
286. In a preferred embodiment, the data handler 272 
converts data from an external source into a database table 
for the appropriate PID. Lastly, the data manager 202 

50 incorporates converted data 288 into the patient record. 
Otherwise, the interface manager 270 reports an error 289. 
The data manager 202 may recover from the error 289 in 
several ways. First, the data manager 202 may invoke a 
module to register an interface for the external source so as 

55 to allow the process to continue. Second, the data manager 
202 may end the process at this point. Lastly, the data 
manager 202 may restart the process in the event the external 
source was specified incorrectly. 

Referring now to FIG. 17b, an external source requests 

60 data 290 from a patient record. As described above, the 
interface manager 270 determines at 292 if the registry 
includes an interface for the external source. As determined 
at 292, if the registry includes an interface for the external 
source, the data manager 202 locates the requested data at 

65 294 and the data handler 272 converts requested data at 296 
to the format required by the external source. The commu- 
nication interface 274 then sends the converted data to the 
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external source at 298. For example, the patient data reposi- 
tory 102 may transmit a physician's prescription for medi- 
cation to a hospital or pharmacy. If the registry includes no 
interface for the external source, the interface manager 270 
reports an error 299. Similarly, as discussed above for the 
process flow of FIG. 17a, the interface manager 270 may 
recover from the error 299 by restarting the process, ending 
the process or invoking a module to register the external 
source to allow the process to continue. 

Referring now to FIG. 18, a block diagram illustrates the 
structure of the optional reference database 104 (FIG. 1). 
The reference database 104 includes a diagnosis module 
300, a medication manager 302 and a procedure module 
304. A healthcare provider can use the reference database 
104 for assistance in diagnosing a patient's disease, pre- 
scribing medications and ordering supplemental procedures 
to treat the disease. The diagnosis module 300 communi- 
cates with a medication manager 302 to obtain information 
on medications indicated by a diagnosis. The medication 
manager 302 provides information on medications, such as 
proper dosages, allergies, contraindications, adverse inter- 
actions with other medications, and side effects. The diag- 
nosis module 300 likewise communicates with a procedure 
module 304 to obtain information on the proper adminis- 
tration of procedures indicated by a diagnosis. The proce- 
dure module 304 provides information on procedures for 
treatment as indicated by the diagnosis. In many instances, 
the medication manager 302 communicates with the proce- 
dure module 304 regarding the administration of various 
medications. 

In a preferred embodiment, the point of care system 100 
provides access to the reference database 104 through a 
graphical user interface having a patient chart window 310 
shown in FIG. 19. A healthcare provider accesses the 
diagnosis module 300 and the procedure module 304 by 
pointing and clicking on a reference access button 312. 

As shown in FIG. 20, the reference access button 312 
produces a reference window 330 including the graphical 
interfaces for the diagnosis module 300 and the procedure 
module 304. For example, to enter a diagnosis, a physician 
clicks on the scroll down button 331 adjacent to the system 
box 332 to produce a list of body systems. The physician 
selects the appropriate system and the diagnosis module 300 
enters the selected system in the system box 332 and 
provides a list having specific diagnosis codes for the 
selected body system in the diagnosis box 334. The physi- 
cian then selects the appropriate diagnosis code and clicks 
on the add button 336 adjacent to the diagnosis selection box 
337. The diagnosis module 300 enters the selected diagnosis 
code to the diagnosis selection box 337. The physician may 
repeat the above steps to add multiple diagnosis codes to the 
diagnosis selection box 337. In a similar manner, a physician 
uses the scroll down button 331 adjacent to the topic box 333 
to select the appropriate procedure topic. The procedure 
module 304 enters the selected procedure topic in the topic 
box 333 and provides a list of procedure codes in the 
procedure box 335. The physician now selects the appro- 
priate procedure code and adds it to the procedure selection 
box 338 by clicking on the add button 336 adjacent to the 
procedure selection box 338. The physician may likewise 
repeat the above steps to add multiple procedure codes to the 
procedure selection box 338. The physician completes entry 
of diagnoses and procedures by clicking on the done button 
339 to return to the patient chart window 310 of FIG. 19. 

The healthcare provider similarly accesses the medication i 
manager 302 (FIG. 18) by clicking on a medication button 
192 (FIG. 19). Referring now to FIG. 21, the medication 
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button 314 activates a medication manager window 350. The 
physician can review the patient's history by viewing the 
medication history box 351 and the diagnosis history box 
352 before prescribing any new medications. The physician 
5 can also review any patient allergies in the allergy box 353. 
The physician can select a medication by entering the name 
of the medication in the name box 354. Note that as the 
physician enters the root letters of a medication name, a list 
of medications with the root letters appears in the medica- 

10 tion list box 355. As before, the physician selects a medi- 
cation from the list by clicking on it and the medication 
manager 302 places the selected medication in a selection 
box 356. If there are no contraindications or allergies for the 
patient, the physician prescribes the medications listed in the 

15 selection box 356 by clicking on the prescribe button 357. 
Otherwise, if a contraindication exists, a warning appears 
in a warning bar 358 to alert the physician. In view of the 
warning, the physician can investigate the effects of the 
medication by clicking on the results button 359. Referring 

20 now to FIG. 22, the results button produces a medication 
interaction window 361. A medication selection box 362 
displays the medications selected and under consideration 
by the physician. An allergy list box 363 displays the 
patient's allergens. Folder tabs 364 include labels describing 

25 the medication combinations and interactions. The physician 
clicks on one of these folder tabs 364 to display the contents 
of the folder in the viewing box 365. The physician can then 
evaluate the information on the interaction including poten- 
tial adverse patient reactions. The physician clicks on the 

30 done button 366 to return to the medication manager win- 
dow 350 of FIG. 21. The physician can make any needed 
revisions to the medications selected in the manner 
described above. Afterwards, the physician exits the medi- 
cation manager 302 by clicking on the exit button 360. 

35 Referring now to FIG. 23, a block diagram illustrates the 
structure of the optional legacy data system 106 as shown in 
FIG. 1. The legacy data system 106 includes a data source 
370 and a converter 372. The data source 370 comprises 
physical data 374, such as paper based records and 

40 photographs, and electronic mainframe data 376. The con- 
verter 372 receives information from the data source 370 
and transforms the information into an electronic format 
compatible with the EMR system. For example, to input 
physical data 374, such as paper or image based data, into a 

45 patient record, the converter 372 comprises a scanner to 
digitize the physical data into a binary file format for 
incorporation into the patient's record. To input electronic 
mainframe data 376, the converter 372 employs the same 
mechanism used for transfer or receipt of patient data from 

50 external sources. As described before, the converter 372 
determines if an interface exists for the mainframe data, 
selects the appropriate data handler and converts the data 
into the proper format for incorporation into a patient record. 

55 II. EMR System Configurations 

FIG. 24 illustrates one possible configuration for the EMR 
system of the present invention. The system comprises a 
wide area network (WAN) 402, the World Wide Web (Web) 
404 portion of the Internet, and remote web servers 406, 

60 408, 410 communicating with web browsers 412. The WAN 
402 comprises a plurality of local area network (LAN) 
servers supporting local and remotely located healthcare 
providers. For example, the WAN 402 includes LANs sup- 
porting Scripps Health 414 and Sharp Memorial 430 in San 

65 Diego and Cedars Sinai 432 and Loma Linda 434 in Los 
Angeles, Calif. In one presently preferred embodiment, the 
server comprises a multi-processor personal computer hav- 
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ing Intel Pentium processors, such as a Compaq Proliant definition, data access, security, programming language 

450OR 5/100 Model 2, communicating with a fault tolerant, interface and data administration. The SQL-92 standard 

error correcting storage device, such as a Hewlett Packard specifies data definition, data manipulation, and other asso- 

20XT Optical Jukebox having 20 gigabytes of storage ciated facilities of a DBMS that supports the relational data 
capacity. The LAN 400 includes a backup server 426 and 5 model . SQL is old in the art and additional information on 

several peripherals, such as a scanner 424 to input docu- SQL-92 is available in ANSI specification X3.135-1992, 

ments and a laser printer 422 to print out documents. In a hereby incorporated by reference 

preferred embodiment, the LAN backbone comprises an sjmilarl in ano , her fcrred embodimelll> relational 

Ethernet twisted pair cable configured in a general star dttaballes in the EMR t em s rt me 0 p eD Database 

Mino°l£v y ' S ? D f Der v™f 5mPri r S . a , FUJI fi 11 10 Connectivity (ODBC) model. ODBC is an application pro- 
M3093EX scanner using KMax KIPP ImageControls soft- (Apl) { hal aU(JWS ^ a Ii ^ ions ^ 

ware and the laser printer 422 comprises a Hewlet Packard under Microsoft windows , 0 access varf Q B f 

LaserJet 4Plus. Healthcare providers may access the LAN data ^ inch)din relationa , and non . reUtional DB MS. 

400 using a desktop computer 416, a laptop computer 418 or ^ da(a reside Qn a cKent Qr 

wire ess pen computer 420. In a preferred embodiment Jhe I5 be on , remotfi ^ communicatl mrou ^ 

xf ^1 P «°n nlP !; , """P" 565 'StS"™ Desk P ro , 5 '" a network common to the client machine. Under ODBC, 
^ fp^n P ,T mPllter , composes a IBM data m in ^pkri,, from shrink-wrap 

imnwaa /oucu and roe pen computer 4ZU compnses a database „ such 

as Microsoft Access, running under Win- 

pr£ a y 1 T . C0 ° fig ^ ™? 3 r^M t6k ^^r 1 dows ° n a clien < '"^hine to more sophisticated, proprietary 

PCMCIA network adapter for wireless LAN access. The ? n ™io ( ;™i nm^c : tt • • c 

• , r 20 relational DBMS running on a Unix server or mainframe 

EMR system also provides for communication through the er For , ^ a ucation to access data from , da , a 

World Wide Web^or example, remote healthcare provtders , d jc |ink hb ^ driver mus , exis , for 

may access the WAN 402 on the Web using the domain each data ^ to ^ access ^ For additional information 

name wwwwestcsiLcom 436. Thus, a healthcare provider on 0DBC ^ avaiIab , e from Insj(Je 0DBC b ^ Gei 

located in Boston, Mass. may access a patient record rest- „ hereb iDCOrporated b rcfcrcnce . 

dent on the Scripps Health server 414, located in San Diego, 

Calif., using a web browser 412, such as Microsoft Explorer II • SUMMARY 

or Netscape Navigator, communicating with a Web server in The electronic medical record system of the present 

Boston, Mass. having the domain name "www.boston.com" invention advantageously overcomes several limitations of 

'W*. 30 existing technologies and alternatives. Because it is more 

In a preferred embodiment, servers 414, 426, desktop 416, efficient and cost effective to move data, instead of physical 

or laptop 418 computers and peripherals, such as printers records and healthcare providers, the present invention 

422 or scanners 424, communicate with each other and with eliminates the need to create and maintain any physical data 

the Web using a network operating system, such as records. In contrast to other systems, the present invention 

Microsoft Windows NT, Windows 95 or Windows for Work- 35 creates and maintains all patient data electronically. Thus, 

groups. Similarly, pen computers 420 use the Microsoft there is no need to find, pull, move, update, file and replace 

Windows for Pen Computing operating system. In another physical charts. As a result, healthcare providers no longer 

preferred embodiment, the servers, computers and periph- require substantial shelving and storage space for physical 

erals communicate using an operating system supporting files. The present invention likewise eliminates the 

Web browsers on computer networks, such as Unix, Novell 40 mishandling, loss and destruction of patient data typically 

Netware or Apple System 7.0. In yet another preferred associated with maintenance of physical data records, 

embodiment, the EMR system includes servers, computers Using the present invention, healthcare providers enter 

and peripherals networked using mixed network operating patient data immediately at the point of care. Thus, the EMR 

systems, such as Unix, Netware and Windows. For example, system captures each piece of data at its source at the time 

the LAN 400 may operate on a Windows NT network 45 of entry, including time and healthcare provider identifica- 

operating system, whereas the LAN 430 may operate on an tion. The EMR system thus provides a complete audit trail 

Apple System 7.0 network, and the Web server "www.bos- for all patient data. The audit trail, in rum, permits inexpen- 

ton.com" 406 may operate on a Unix operating system. s ive analysis of outcomes, utilization and compliance. For 

Thus, the EMR system supports communication among a example, outcomes typically refer to the effectiveness of a 

variety of hardware components, such as printers 422, 50 treatment plan. Thus, the EMR system enables a healthcare 

scanners 424 and pen computers 420, using a variety of provider to analyze patient recovery times and incurred costs 

network operating systems, such as Windows, Netware or to measure the efficacy of the treatment plan. Similarly, 

Unix. In a preferred embodiment, healthcare providers, such utilization typically refers to how well available resources 

as clinics and laboratories, may also communicate with the are utilizing time. Thus, the EMR system provides the 

EMR system using modem links and standard v.34 modem 55 capability to analyze utilization of physicians, nurses, staff 

devices, such as a US Robotics Sportster 28,800 modem. and equipment as well as time utilization for patients, such. 

The EMR system includes several databases of electronic as wait times for referrals, lab results and physician exami- 
information, such as the medication manager 302 and the nations. Lastly, compliance typically refers to conformance 
data manager 202. In a preferred embodiment, the EMR with government and accreditation standards and regula- 
system implements a relational database language that con- 60 tions. The EMR system provides tools to enable healthcare 
forms to American National Standards Institute (ANSI) providers to measure conformance to standards and regula- 
standard SQL-92, a 580 page specification* for the SQL tions. To facilitate entry of patient data at the point of care, 
relational database language. A database language standard the invention provides touch screens for entry of lab orders, 
specifies the semantics of various components of database medications, diagnoses and procedures. The invention like- 
management systems (DBMS). In particular, it defines the 65 wise provides instant access to a patient's electronic medical 
structures and operations of a data model implemented by record by authorized healthcare providers from any geo- 
the DBMS, as well as other components that support data graphical location. Thus, the EMR system enables autho- 
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rized healthcare providers to access and update patient files 
using wireless pen-based personal computers. In addition, 
authorized healthcare providers can access a record while 
other healthcare providers use the same record. By provid- 
ing simultaneous access to patient data, the present inven- 5 
tion enables real-time collaboration among multiple health- 
care providers. 

The availability of electronic data permits instant, sophis- 
ticated analysis of a patient's clinical data. Thus, the EMR 10 
system can create graphs of a patient's vital signs and lab 
results or the system can provide an analyze patient infor- 
mation to identify medication interactions and allergies. 
Using the present invention, a healthcare provider can 
likewise select, sort, and analyze patient data to identify 15 
relationships among the data considered. In addition, the 
EMR system provides flexibility in the creation and main- 
tenance of patient data repositories. Thus, the present inven- 
tion can support a large healthcare enterprise distributed 
across a large geography as well as a single physician office. 20 
Moreover, the present invention ensures patient confidenti- 
ality through the use of a tiered password system. The EMR 
system provides several levels of security for access to 
patient data. For example, a system administrator may have 
global password access to any patient data for system 25 
maintenance and debug purposes, whereas physicians may 
have access only to patient records within their specialty and 
nurses and staff may have access to only those patient 
records within their immediate care. In addition, a patient 
may request restricted access to their data by only certain 30 
personnel. Thus, in contrast to physical records, the EMR 
system provides superior protection of patient data. 

In addition, the present invention is useful in legal, 
manufacturing and general administration environments. 35 
For example, the present invention is capable of organizing, 
maintaining and protecting legal files in an attorney's office. 
Thus, the EMR system can store and retrieve scanned 
images of paper documents, such as deeds and assignments, 
as well as other native file formats, such as word processing 
files. The EMR system organizes and retrieves this data in a 
manner akin to that of a patient's medical record. Upon entry 
of a client data into the EMR system, attorneys can annotate 
documents, transfer information to and from other systems, 
or create new data for automatic filing in the client or case 
file. Similarly, the EMR system is useful for management of 
procurement or regulatory data in a manufacturing context. 
Thus, the EMR system can organize and maintain material 
safety data sheets (MSDS) as well as other data pertinent to 
materials procurement, such as conformance to specification ^ 
measurements and inspection data for received lots, in a 
manufacturing environment. Lastly, the EMR system is 
useful for general administrative files in any organization. 
For example, the present invention is applicable to employee 
files in human resources, customer files in sales and 
approved suppliers in procurement. The EMR system can 
organize and retrieve data within these files in the manner as 
patient data in a patient data record. As discussed above, 
upon entry of a data into the EMR system, users can annotate 
documents, transfer information to and from other systems, 6Q 
or create new data for automatic filing in the respective file. 

Those skilled in the art may practice the principles of the 
present invention in other specific forms without departing 
from its spirit or essential characteristics. Accordingly, the 
disclosed embodiments of the invention are merely illustra- 65 
live and do not serve to limit the scope of the invention set 
forth in the following claims. 
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What is claimed is: 

1. A medical records system, comprising: 
a point of care system to capture patient data at a point of 

care wherein the point of care system comprises: 
patient data capture to enter information provided by a , 
patient, 

a clinical data capture, in data communication with the 
patient data capture to enter clinical data for the patient, 

an encounter data capture, in data communication with 
the patient data capture, to enter diagnoses and proce- 
dures administered to the patient, and 

progress notes, in data communication with the patient 
data capture, the clinical data capture and the encounter 
data capture, to enter information related to changes in 
the patient's condition, and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

2. The medical records system of claim 1, further com- 
prising a medication data capture, in data communication 
with the patient data capture and the progress notes, to enter 
medication information for the patient. 

3. The medical records system of claim 1, further com- 
prising a practice guideline for reference to accepted medi- 
cal practices, wherein the practice guideline communicates 
with the patient data capture, the clinical data capture, the 
progress notes and the encounter data capture. 

4. The medical records system of claim 3, further com- 
prising a medication data capture, in data communication 
with the patient data capture, the progress notes and the 
practice guideline, to enter medication information for the 
patient. 

5. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that accepts SQL data queries. 

6. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises a 
server computer having access to patient data stored in 
a relational database that is ODBC compatible. 

7. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system, wherein the patient data repository comprises: 
a patient locator having a patient identifier, 
a data manager, in communication with the patient 
locator, to organize patient data for storage and 
retrieval using the patient identifier, and 
a data interface, in communication with the data 
manager, to transmit patient data to external systems 
and to receive patient data from the external systems. 
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8. The medical records system of claim 7, wherein the 
patient data repository further comprises: 

a cache, in communication with the data manager, to 
temporarily store the patient data for retrieval; and 

a data archive, in communication with the cache, to 
permanently store the patient data. 

9. The medical records system of claim 8, wherein the 
cache is located on a server computer. 

10. The medical records system of claim 8, wherein the 
cache is distributed across a computer network. 

11. The medical records system of claim 8, wherein the 
data archive comprises a jukebox having at least one storage 
device. 

12. The medical records system of claim 11, wherein the 
at least one storage device is a recordable optical disk. 

13. The medical records system of claim 11, wherein the 
at least one storage device is a magnetic disk drive. 

14. The medical records system of claim 7, wherein the 
data interface comprises: 

a communication interface to send and receive patient 
data from external systems; 

an interface manager, in communication with the com- 
munication interface, to set the communication inter- 
face for either transmission or receipt of the patient data 
from the external systems; and 

a data handler, in communication with the interface 
manager and with the communication interface, to 
convert selected patient data into a selected data format. 

15. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a reference database in communication with the point of 
care system. 

16. The medical records system of claim 15, wherein the 
reference database comprises: 

a diagnosis module having diagnosis codes indicative of 
a condition of a patient; 

a procedure module, in communication with the diagnosis 
module, having procedure codes indicative of a treat- 
ment to administer to the patient; and 

a medication manager, in communication with the diag- 
nosis module and with the procedure module, having 
information on medication to administer to the patient. 

17. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care; 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system; and 

a legacy data system in communication with the patient 
data repository. 

18. The medical records system of claim 17, wherein the 
legacy data system comprises: 

a data source having patient data; and 

a converter, in communication with the data source, to 

convert the patient data into a selected format for 

transfer to the patient data repository. 

19. The medical records system of claim 18, wherein the 
data source comprises physical data. 
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20. The medical records system of claim 18, wherein the 
data source 20 comprises a mainframe computer having 
electronically stored patient data. 

21. The medical records system of claim 18, wherein the 
converter comprises a scanner. 

22. A medical records system, comprising: 

a point of care system to capture patient data at a point of 
care wherein the point of care system provides for 
annotation of the patient data; and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the patient data for access by the point of care 
system. 

23. The medical records system of claim 22, wherein the 
annotation acknowledges review of the patient data. 

24. The medical records system of claim 22, wherein the 
annotation includes instructions for patient care. 

25. The medical records system of claim 22, wherein the 
annotation indicates approval. 

26. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises inter- 
face files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

27. A medical records system, comprising: 

a point of care system to capture data at a point of care; 
and 

a patient data repository, in communication with the point 
of care system and with external systems, to store and 
organize the data in a patient record for access by the 
point of care system, wherein the data comprises legacy 
files and wherein the patient record includes, 
a patient identifier, and 

at least one data structure including the patient identi- 
fier and the data. 

28. A method of using an electronic medical records 
system, comprising the steps of: 

capturing patient data electronically at the point of care; 
organizing the patient data so as to form a patient record; 
filing the patient record; and 

retrieving the patient record to access the patient data for 
use in the care of a patient. 

29. The method of claim 28, wherein the step of retrieving 
the patient record includes annotating the patient data. 

30. The method of claim 28, further comprising the step 
of evaluating the patient data so as to make a diagnosis. 

31. The method of claim 30, wherein the step of evalu- 
ating the patient data comprises consulting a diagnosis 
module to review diagnosis information. 

32. The method of claim 30, further comprising the step 
of prescribing a medication. 

33. The method of claim 32, wherein the step of prescrib- 
ing a medication comprises consulting a medication man- 
ager to review medication information. 

34. The method of claim 30, further comprising the step 
of administering a treatment. 

35. The method of claim 34, wherein the step of admin- 
istering a treatment comprises consulting a procedure mod- 
ule to review procedures to administer the treatment. 
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36. A method of retrieving patient data in an electronic 
medical records system having a patient data repository, 
comprising the steps of: 

obtaining a patient identifier; 

locating a patient record corresponding to the patient 5 

identifier in the patient data repository; 
determining the location of the patient data within the 

patient record. 

37. The method of claim 36, further comprising the step 
of delivering the patient data. 

38. The method of claim 36, wherein the patient data 
repository includes a cache and a data archive. 

39. The method of claim 38, further comprising the step 

of delivering the patient data when the patient data is located 15 
in the cache. 

40. The method of claim 38, further comprising the steps 

of: 

moving the patient data from the data archive when the 

patient data is not located in the cache; and 2 o 
delivering the patient data. 

41. A method of managing a patient data repository 
having a cache and a data archive, comprising the steps of: 

monitoring a status of data within the cache; and 
moving the data to the data archive when the status 25 
exceeds a threshold. 
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42. The method of claim 41, wherein the threshold 
comprises a selected time and the status comprises the 
duration of time the data has been in the cache. 

43. The method of claim 41, wherein the threshold 
comprises a selected portion of the storage capacity of the 
cache and the status comprises the filled portion of the 
cache. 

44. A method of communicating with an external source 
having an interface to an electronic medical records system, 
comprising the steps of: 

finding an interface for the external source; 
connecting to the external source using the interface; and 
converting patient data for transfer between the external 
source and the electronic medical records system. 

45. The method of claim 44, wherein the step of convert- 
ing patient data for transfer comprises converting patient 
data for transfer from the electronic medical records system 
to the external source. 

46. The method of claim 44, wherein the step of convert- 
ing patient data for transfer comprises converting patient 
data for transfer from the external source to the electronic 
medical records system. 

* * * * * 
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[57] ABSTRACT 

A distributed database architecture stores medical informa- 
tion in a self-updating system that employs point-of-service 
stations disposed at convenient medical service locations. 
Each patient carries a portable data carrier such as a smart 
card that contains the patient's complete medical history. 
Interaction between the portable data carriers and the point- 
of-service stations effects a virtual communication link that 
ties the distributed databases together without the need for 
online or live data connections. The point-of-service stations 
are also interconnected over a communications network 
through a switching station that likewise does not rely on 
online, live communication. The database system uses an 
object-oriented update object to distribute data that has been 
generated when a portable data carrier is not physically 
present and to automatically distribute data without the 
necessity of accessing a masterfile. 
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METHOD AND SYSTEM FOR MAINTAINING coordinated and updated at one main site and then must be 

AND UPDATING COMPUTERIZED made available, in whole or in part, to peripheral dependent 

MEDICAL RECORDS locations. 

_ , n t k rt „ mm In order to have access to current data, these traditional 

BACKGROUND AMDSUMMARY OF THE s systems mllsl hc ^^jy available 0? . Uoe . and „ lbe 

complexity of the transaction-based application increases, 

A. Field of the Invention overload and bottleneck problems ensue; and the commu- 
The present invention relates generally to computerized nication channels become more complicated and costly. 

medical information systems. More specifically, it relates to Furthermore, the integrity of the whole network continu- 

maintaining and updating computerized medical records. 30 ousl y ™ d precariously depends on the reliability of these 

The invention is based on a distributed database network physical communication channels, 

architecture, in which a plurality of portable data carriers To date > accessing a central file, at some point, is the only 

(PDCs) and point-of-service (POS) stations interact to main- networking solution that allows for the coordination of data 
tain the currency of the medical records of a plurality of updates that have been generated at geographically distinct 

patients. Each PDC contains the medical record of an locations. And unfortunately, all of these network systems 

individual patient. Each POS station contains a system for experience overload, bottleneck, service interruption or 

generating and propagating medical data specific to that coordination delay problems, because of their need to update 

medical care site. and men redistribute, data from a masterfile. 

The PDCs and POS stations contain independent, but 20 Outpatient medical transactions are so diverse, as well as 

interrelated, databases; and a major function of the presently bein g 50 geographically and temporally complex, that the 

described invention is to keep the information in these anticipated problems of data access, data currency and cost 

databases current. °f me traditional centralized systems, become prohibitive. 

In addition to serving as one of the database repositories ™ " asons . lherc «* » 

in this network, each PDC also selves as a communication 25 succe »£ui. broad-based computerized outpatient medical 

link between the POS stations. Each patient carries their own re cor systems. 

medical record from one station to another on their own SUMMARY OF THE INVENTION 
PDC. 

_ , , . . t . . The present invention takes a different approach. It does 

Furthermore, the invention utiles object-oriented tools d d Qn ^ C6 of , cenlra , datab Qr ^ 

and structures that include: (1) dynamic objects called 30 masle i le . It ^ a ; ew typc of distributed database 

update objects and (2) data processing "rule sets which jn ^ m ^ ^ ^ are automa|ican 

are stored throughout the above described network, working aUd from ^ si(es of orf ■„ tQ seyera , mwat ^ 

together, these update objects and rule sets establish, route, * ^ M.pendeiiUy Mid selectively. The memory 

organize, store and update the medical information of a sftes ^ jn . (1) >^ (pl / c) (2) medic > 

plurality 01 patients 35 poi[lt _ 0 f. servi ce (p 0 s) stations and (3) administrative ser- 

B. Descnption of Related Art vices systems . 

The healthcare industry has long recognized the need for Although the presently described system is applicable to 
a computerized medical information system that can main- inpatient medical care, it is most advantageous in the out- 
tain a comprehensive and current record of each patient's p a tient setting 

medical status over space and time. " In ^ preseDlly preferfed embodiment) me PDC is a 

Although keeping such ^formation m computerized data- microprocessor integrated circuit chip card, commonly 

bases might seem simple, providing efficient and cost- known as a smart card. This card serves as a data storage 

effective access to those databases and keeping all data in the dcvicc on which pat ients carry a copy of their own medical 

databases current, are daunting tasks due to some technical record 

inefficiencies in traditional distributed database systems, and 45 Each card can carry a significant amount of medical data . 

due to the size and mobility of patient populations. Jn ^ present embodiment) mis i^des, but is not restricted 

Whereas, it has been possible to successfully implement to: diagnoses, surgeries, obstetrical data, status of therapeu- 

traditional centralized on-line computer information systems tic treatments, diagnostic test results, current and past 

for geographically limited populations, such as within SQ medications, allergies, diet, durable medical equipment, 

hospitals, it has not been possible to simply scale-up these blood type, advanced directives, immunizations, birth data, 

systems to accommodate larger, more disperse patient popu- soc i a i history, family history, physician office visits, hospi- 

lations in the outpatient setting. talizations and emergency room visits. In addition, the card 

The complex, wide-spread interactions of medical outpa- carries physician orders, such as medication prescriptions, 

tient care require a wide area network architecture. 55 laboratory or X-ray tests, referrals to consultant physicians, 

However, available distributed database networks exhibit surgical procedures and the like. All of this data is directly 

significant shortcomings when they are applied to electronic transported between the POS stations of the system on the 

data interchange applications that entail complex indepen- PDCs. 

dent transactions at numerous disparate point-of-service The POS stations are computer systems positioned at 

locations. 60 locations where patients receive medical care, such as phy- 

The major problems that make traditional network models sician offices, pharmacies, laboratories, radiology units, 
unsuitable for many point-of-service applications, such as hospitals, diagnostic and treatment centers, emergency treat- 
outpatient medical care, are: (1) inefficient access to needed ment sites and urgent care centers. Each of the POS stations 
data, (2) difficulty in maintaining data currency throughout may be custom -configured to that provider's specific medi- 
the system and (3) cost. $5 cal application. 

From the data access standpoint, traditional transaction- For example, a physician office POS station may, among 

oriented networks define a master data file which must be other functions, generate new diagnoses and physician 
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orders; and may store and have access to the entire medical transaction at a POS station. Examples of such data would 
record of all the patients that are cared for at that particular be an X-ray report or a laboratory test result. In addition to 
site. Whereas, a pharmacy POS station, in addition to other this basic core of medical data, each update object also 
functions, may read the medication prescription orders that contains processing tags. These tags, along with correspond- 
are designated on the patient's PDC; and further, may 5 ing data processing "rule sets" located throughout the 

indicate on the PDC that the medication has been dispensed. system, guide each update object to its targeted PDC, POS 
However, the pharmacy POS station may not have read or and administrative databases, independently. Furthermore, 
write access to any other portion of the patient's PDC the processing tags and rule sets also function to automati- 

record. cally assimilate the data element into the independent data- 

This independent PDC-POS database design allows 1Q bases, 

"patient specific" and "site specific" medical data to be The update object is designed to distribute data that has 

present when and where it is needed, at every medical POS been generated when a PDC is not physically present, such 

location. Each patient carries their own medical record with as a laboratory test result which becomes available after the 

them to each POS site, thus resolving the issue of timely and patient has already left the laboratory. Also, it is designed to 

efficient access to data. Bottleneck, system overload and automatically distribute data without needing to access a 

service interruption problems are avoided. 15 masterfile. 

Besides serving as data memory sites, the PDCs also serve For example, an update object may be created at a 

as one of the main communication links between POS laboratory POS station. The update object contains a test 

stations. Stored within their PDC, patients actually carry result and is tagged with specific destination identifiers such 

their medical data from one POS station to another. We are as the POS address of the patient's primary physician, 

describing this aspect of the invention as "off-line*' 20 ^ update ob j cct ^ ^ ta routed through a switching 

communication, to distinguish it from "traditional on-line" station which is essentially an electronic data exchange 

communication. For transaction-based applications, "on- system containing rule sets designed to propagate the medi- 

Une" implies continuous availability of a physical telecom- ca i data over traditional communication channels from one 

munication link and live or real-time data transfer. In network POS station to any other station. The system is not 

contrast, by carrying their own data with them, the PDCs 25 dependent on a specific method of data transmission, 

allow intermittent, focused, "off-line" coupling, which is This system does m ^ from lradilional switching 

much more efficient and much less expensive. mechanisms, in that, rather than routing update information 

By way of brief illustration, when a patient visits their to a single masterfile, each data element is automatically 

doctor, the patient's PDC is read by the doctor's POS station routed to any Q f a niJm b e r of distributed databases through- 

and this automatically transfers medical information 30 out the network. Furthermore, all data is routed selectively, 

between the PDC and the station, so that the more current meaning that it is only transported to locations at which it is 

data is propagated and stored in both places. needed. This system provides significant data processing 

Thereafter, the doctor may diagnose an illness, and pre- efficiency. Also, communication between each POS station 

scribe certain medications. This information is input and an d the switching station only needs to occur intermittently, 

stored in the doctor's POS station and also transferred to the 35 resulting in significant cost savings, 

patient's PDC before they leave the office. when the update object arrives at the physician's POS 

Later, when the patient visits the pharmacy to fill the station, it is stored in the database and it is also transferred 
prescription, the patient's PDC is read by the POS station at to the patient's PDC, the next time the patient arrives for 
the pharmacy. This causes the current prescription informa- ^ medical care. In addition to direct PDC-POS communication 
tion to be propagated to the pharmacy station. It may not be linkages, this update object -switching station design pro- 
necessary for the pharmacy POS station to have access to all vides a second automatic and selective mechanism for the 
of the medical information on the PDC. Indeed, some of the POS stations and the PDCs to remain current without 
information may be confidential or unnecessary to filling the needing to access a masterfile. 

prescription. The internally stored rule sets in the pharmacy ^ \ n add jti 0 n to the above advantages, each update object 

POS station govern what information can be obtained from persists in critical locations throughout the network, until the 

the PDC and what information is excluded. data element it contains has successfully reached all desig- 

The pharmacy then inputs its data related to filling the nated databases. This feature provides significant data secu- 

prescription, thus updating the PDC further. The pharmacy rity and does not rely on the continuous integrity of the 

POS station also stores the data it generated in its own 5Q telecommunication linkages to assure that data is appropri- 

internal memory. ately propagated. 

In the preceding illustration, only two stations were As mentioned previously, this system also contains an 

described. However, as indicated previously, the system administrative services system which provides the manage- 

contemplates a plurality of POS stations, each being custom- ment services related to medical activities services such as 

configured to that provider's medical application. 55 data backup, billing, medical and financial auditing, and 

These POS stations are all in "virtual" communication report generation, 

with each other because the collective rule sets of the system One of the key concepts of this invention is the estab- 

are designed to propagate data from one station to another, lishment of a network of truly independent databases, which 

using the PDCs as the communication medium rather than are connected by "virtual" communication systems and are 

traditional telecommunication channels. 60 automatically modified and kept current, without accessing 

Furthermore, a second type of "virtual" communication a masterfile. This concept is made functional by combining 

system has been designed which does utilize traditional PDCs, which are both independent databases and "off-line" 

telecommunication channels; but describes an alternate communication channels, with independent POS stations 

method of propagating data over these channels. The data is and administrative services systems, all utilizing flexible and 

transmitted via "update objects." $5 unique computer tools and rules. 

The core of each update object is an element of informa- This invention provides a practical, efficient, and cost- 

tion or an item of data that has been generated by a medical effective solution to the problems associated with complex, 
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high-volume, transaction-oriented networking applications, 
sucb as outpatient medical information systems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a system overview block diagram of the pres- 
ently preferred system for maintaining and updating com- 
puterized medical records; 

FIG. 2 is a block diagram illustrating the presently pre- 
ferred field object data structure; 

FIG. 3 is a block diagram illustrating the presently pre- 
ferred record object data structure; 

FIG. 4 is a block diagram illustrating the presently pre- 
ferred update object data structure; 

FIG. 5 is a table diagram illustrating the overall database 
structure employed by the presently preferred implementa- 
tion; 

FIG. 6 is a block diagram illustrating the principal sub- 
systems employed in the portable data carrier, the point-of- 
service station, the switching station and the administrative 
services system; 

FIG. 7 is a block diagram describing the rules set of the 
presently preferred implementation, illustrating the pres- 
ently preferred locations at which the rules are implemented; 

FIG. 8 is a block diagram of the switching station archi- 
tecture; 

FIG. 9 is a block diagram illustrating the rules set used by 
the presently preferred embodiment to handle communica- 
tions and updates between the portable data carrier and 
point-of-service station databases; 

FIG. 10 is a block diagram illustrating the process by 
which an update object generated by a point-of-service 
station is propagated; 

FIG. 11 is a block diagram illustrating the process by 
which an update object received from a switching station is 
propagated; 

FIG. 12 is a block diagram illustrating the processing 
rules employed by the preferred embodiment in routing an 
update object through the entire system. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

II System Overview 

FIG. 1 illustrates the basic components of the presently 
preferred medical information system. The system includes 
a plurality of portable data carriers (PDCs) 100, and medical 
point-of-service (POS) stations 110, one or more switching 
stations 140 and one or more administrative services sys- 
tems 150. 

A Portable Data Carrier 100 

The presently preferred PDC is an integrated electronic 
circuit chip card containing a microprocessor and memory 
and it is commonly known as a "smart card/' It has data 
processing and memory capabilities. It may contain an 
independent, on-board power source and a digital display. It 
serves as a data storage medium and a communication 
device. 

The smart card is presently preferred, because it is rela- 
tively economical and may easily be carried in the purse or 
wallet. It has sufficient memory capacity to store a patient's 
entire medical record; it has processing capabilities to 
handle changes in the medical record; it can accommodate 
administrative functions such as demographic changes and 
financial transactions; and it has numerous inherent security 
features to accommodate medical privacy and confidential- 
ity concerns. 
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By integrating software and hardware design, each PDC 
is structured to communicate with a plurality of medical 
POS stations. In the presently preferred embodiment, the 
PDC communicates with the POS stations through electric 
5 contacts, although con tactless interface is also possible. 
As depicted in FIG. 6, the presently utilized PDC con- 
ceptually has four principle subsystems: a communication 
manager 101, a file manager 102, a security manager 104 
and a file system (database) 103. These will be described 

io later. 

B Point-of-Service Station 110 

A medical POS station contains the computer system 
located at any site where medical services can be provided. 
These sites include, but are not restricted to, physician 

15 offices, diagnostic and therapeutic treatment centers, 
laboratories, radiology departments, emergency and urgent 
care treatment sites, pharmacies, hospitals and durable medi- 
cal equipment suppliers. 

In the presently preferred embodiment, the hardware and 

20 software at each site are specific for the particular type of 
medical service provided there. A POS station may be 
implemented using a variety of different personal computers 
loaded with the system's specific operating programs 
described herein. Various peripheral devices such as 

25 touchscreens, scanners and devices with digital interfaces 
such as laboratory test equipment may also be utilized. 

Hie presently preferred embodiment uses a true multi- 
tasking operating system, IBM's OS/2. This allows a POS 
operator to interact with the system with no perceived delay 

30 while the PDC is concurrently being interrogated and 
updated. It also allows several different application pro- 
grams to run simultaneously. This could be advantageous in 
medical offices that want to use their POS stations for 
functions such as word processing, or out-of-system billing 

35 or record keeping. 

The present system utilizes an object-oriented language, 
C++ and object-oriented program and system designs. 

Referring to FIG. 6, presently, the major POS station 
subsystems are: user interface 111, database manager 116, 

40 database 122, patient manager 123, PDC manager 124 and 
communication manager 128. These will be described in 
more detail later. 
C Switching Station 140 
The presently preferred embodiment uses asynchronous 

45 modems to connect each POS station to a switching station. 
Communications over these modems are encrypted to help 
protect the security of the system and to preserve the 
confidentiality of individual patient's medical information. 
The present design utilizes intermittent communication of 

50 batched data. The data that is generated at each POS station 
is temporarily stored on site and then transmitted to a 
switching station, using an u end-of-day" or an "as-needed" 
routine. This is more efficient, less expensive and more 
reliable than continuous on-line communication. 

55 Each switching station may be configured with various 
combinations of PCs, minicomputers, or mainframes. In the 
presently preferred embodiment, the switching station is a 
network of PCs. Each PC contains: a communication man- 
ager module 141 and an "update manager" module 142 

60 (FIG. 6). Together, these two units organize and direct the 
routing of data between various POS stations and also 
between each PO$ station and the administrative services 
system. 

D Administrative Services System 150 
65 An administrative services system deals with the man- 
agement issues related to medical care. The types of services 
provided are optional and can include functions such as data 
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backup, billing, auditing, data analysis and reporting. Each 
system can be constructed using various hardware and 
software combinations to provide particular "customer ser- 
vices." "Customer" refers to anyone who utilizes or benefits 
from the services of the system, such as patients, care 5 
providers, healthcare managers, healthcare payers and 
researchers. 

Each administrative services system may be configured 
utilizing various combinations of PC's, minicomputers or 
mainframes. The presently preferred embodiment builds the aQ 
system around a microcomputer or minicomputer which 
contains: a communication manager 151, an object-oriented 
database 152, a database conversion system 153, a relational 
database 154 and an array of "customer services" 155. See 
FIG. 6. 

Over secure channels, the communication manager coor- 35 
dinates bi-directional communication with the switching 
station. It also provides "external" connections with the 
information systems of customers such as healthcare 
managers, payers and researchers. 

The object-oriented database maintains a copy of the 20 
medical record of all patients using this system. It maintains 
records in the same format as the PDC and POS databases; 
and can be used as a backup resource if there is a breakdown 
in the PDC-POS -switching station portion of the system. 

This preferred embodiment further contains a database 25 
conversion system which converts the object-oriented data- 
base to a relational database. Incorporating a common- 
format, standardized database structure and language into 
the present invention, facilitates functions such as report 
generation and communication with external commercial 30 
systems such as those commonly used by healthcare 
managers, payers and researchers. 

The relational database can be used to simplify numerous 
administrative functions such as financial transactions 
(including billing, payment and account settlements), 35 
auditing, quality assurance, risk management and statistical 
analysis reporting. 

Ill Data and Database Structures 

See FIGS. 2, 3, 4, 5, and 6. 40 
A Overview 

The presently preferred embodiment of this invention 
utilizes object-oriented programming. C++ language is used. 

The invention utilizes numerous classes. The fundamental 
classes of objects used in the system are: field objects 200 45 
(FIG. 2), record objects 220 (FIG. 3) and update objects 240 
(FIG. 4). 

These objects are generated at all POS stations. They are 
then distributed to other POS stations and to PDCs, utilizing 
their own self-contained identification tags and using the 50 
rule sets which exist in various parts of the system. 

For demonstration and discussion purposes, each of these 
objects can be depicted in the form of a "table"; although, in 
the present embodiment, the individual objects and collec- 
tions of these objects, do not actually exist in traditional 55 
"table" form. 

Traditional "table" structure, such as that used in rela- 
tional databases, implies rigid columns and rows with fixed 
field and record sizes. However, in the present invention, 
each of the objects is of variable length; and all objects are 60 
stored in the databases utilizing just as much space as they 
need. Space is not wasted. 

Furthermore, in the present embodiment, data is not 
identified by the fixed row and column it is stored in; rather 
it is stored economically in as little space as possible and it 65 
is identified using a pointer system which indicates the 
position and the length of the stored data package. 



B Field Objects 200 
See FIG. 2. 

Field objects are the smallest objects. In the present 
embodiment, each field object consists of the field type or 
data type identifier, the field length and the field value. The 
data type identifier and the field length both describe prop- 
erties of the field value. 

The data type identifier indicates the category of infor- 
mation that the field value falls under, such as: (1) a CPT 
code identifier of a laboratory test, (2) a "status" indicator, 
or (3) a "result" indicator. 

The field length indicates the amount of storage space that 
the field value requires. 

The field value is the actual value of the data that is being 
identified, such as: (1) the actual numbers of the CPT code, 
(2) the actual status of this test, such as the fact that this is 
a "final result" or (3) the actual result of the test, such as the 
hematocrit value is "40." 

Field type, field length and field value can all be consid- 
ered column headings of a field "table." Each row in the 
"table" describes a certain properly of the data that is being 
identified. The entire "table" can be considered a "collection 
of fields objects" 210 and that collection indicates the basic 
information that is known about that particular item of data 
at that time. 

In this embodiment, field objects do not exist on their 
own, but only exist within record objects. 
C Record Objects 220 

See FIG. 3. 

In the present embodiment, a record object consists of a 
record type identifier, a unique identifier and a collection of 
fields. 

The record type identifier indicates the category of infor- 
mation that the related collection of fields represents, such 
as: laboratory test ordered, laboratory test result, X-ray test 
ordered, X-ray test result, etc. 

The unique record identifier used in this preferred 
embodiment is a time stamp. It is the time in seconds 
measured from midnight Jan. 1, 1970, GMT. 

The collection of field objects has been described above. 
Again, the field value size is flexible, thus making the entire 
record object variable in size. 

The record type, unique record identifier and collection of 
field objects can all be considered as column headings of a 
record "table." Each row in the "table," both generally and 
uniquely identifies the data that is contained in the collection 
of field objects column. 

A record object adds a level of organization to collections 
of fields. 

A record object is the form in which data persists in the 
various databases throughout the system. 

An entire "table" of records is a "collection of records" 
230 and it represents, in an organized fashion, all of the data 
contained in a patient's static medical file. 

In this embodiment, record objects do not exist on their 
own, but only exist within update objects (described below) 
or within databases. 
D Update Objects 240 

See FIG. 4. 

An update object adds a level of organization to a record 
object. 

The update object essentially wraps identification and 
processing information around a single record object and 
becomes the dynamic form of that record object. The update 
object contains the processing tags that guide each record 
object from its point of origin to its intended destination 
database(s) and also the tags that indicate the type of 
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updating process that is to be accomplished when the record 
arrives at its destination databasc(s). 

The update object is a key element of this preferred 
implementation. In conjunction with the processing rules 
that reside throughout the system, the update object allows 
distributed databases to be updated independently, without 
the need of creating or accessing a masterfile. It allows the 
updating process to be completed automatically without the 
need of human intervention. It also assures the accurate 
propagation of update information throughout the system. 
Each update object persists until it has been notified that the 
information it contains has successfully reached its intended 
destinations). 

In this embodiment, the update object consists of: an 
indication of its own length 241, a unique patient identifier 

242. a unique update object identifier 243, at least a single 
record object 220, identification tags of the intended 
destination(s) of this update object (routing tags) 244, the 
update object type identifier (database modification tags) 
245, acknowledgment flags 246 and a variable number of 
audit fields 247. 

Each update object contains an indication of its own 
length 241. This allows for conservation of space throughout 
the system. 

Since the update object is dynamic and moves through the 
system, it must contain a unique patient identifier 242. The 
present embodiment utilizes the PDC's unique serial number 
for this purpose. Other patient identifiers are possible. 

This embodiment uses an update time stamp, similar in 
form to the record object time stamp and an identifier of the 
source POS station as the unique update object identifiers 

243. Other unique identifiers could also be used. 
Each update object contains at least a single record object 

220 as described previously. 

One purpose of the update object is to identify which of 
the distributed databases in the system this particular record 
object should be directed to; and this task is accomplished 
using the identification tags of the intended destinations) 

244. Using these tags and the rule sets that exist in various 
parts of the system, the update object routes itself to the 
appropriate independent databases. 

Furthermore, when the update object arrives at the des- 
tination databases, it interacts with the rule sets contained 
there and deposits its record object in the databases accord- 
ing to its update type identifier 245. 

In the present embodiment, the update type identifier 
indicates the type of processing action that is intended when 
the update object reaches its destination database(s), such as: 
(a) add the enclosed record object to the collection of 
records, (b) delete a record that is already in the database, or 
(c) replace a record object that is already in the database with 
this new record object. 

Whereas record objects are intended to be persistent, 
update objects are transient. They exist for the purpose of 
directing the processing of the record object they contain. 
When that purpose has been achieved, the update object, as 
an entity, can be deleted. The acknowledgment flags 246 are 
this system's method of determining how long a particular 
update object needs to persist in any particular location. 
Essentially, acknowledgment flags are indicators of all of the 
specific destinations that a particular update object must 
reach. 

In operation, it is a copy of each update object that is 
actually propagated through the system. Each update object 
persists at its own originating station; and a copy of that 
object persists at each subsequent station along its propa- 
gating route. 
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The original object and the copies, all persist, until they 
receive notification, in the form of feedback 
acknowledgments, that the appropriate copies have been 
successfully received at all locations in the system for which 

5 the original update object was intended. 

As acknowledgments are received from each intended 
location, the flag 246 for that location is inactivated. When 
all acknowledgments have been received and all flags 
inactivated, the update object is deleted from that particular 

10 part of the system, because it is no longer needed there. 
Therefore, in a static state, a particular patient's medical 
file will only include a collection of record objects 230. 
There will not be a collection of update objects 250. Ihis 
will indicate that all of this patient's medical data has been 

15 successfully distributed to all of the independent databases 
that need it. 

For accuracy and security purposes, each update object 
contains a varied number of fields with auditing tags 247. In 
the present embodiment, combinations of time stamps and 

20 an identifier of the machine that generated the update object 
are used for audit functions. Other identifiers and audit 
protocols are possible. 
E Databases 260 
See FIGS. 5 and 6. 

25 In the present embodiment, object-oriented databases 
exist in each PDC 103, in each POS station 122, and in the 
administrative services system 152. In addition, the pres- 
ently constructed administrative services system contains a 
relational database 154, using a commercially available 

30 database manager. 

The object-oriented databases allow rapid storage and 
retrieval of data in an application specific form. They store 
data in a format that is efficient and appropriate for patient 
encounters at medical point-of-service locations. 

35 The flexibility in size of the field, record and update 
objects allows economical use of space. 

In the present embodiment, the distributed databases 
contain collections of record objects 230 (FIG. 3) and 
collections of update objects 250 (FIG. 4). These are pri- 

40 marily accessed by a key patient identifier, which presently 
is a unique patient serial number. The system also allows 
data access via demographic information, code numbers, 
data type identifiers and the like. 

All of these object-oriented databases are flexible in size 

45 and format. They do not have the rigid structure and space 
restrictions of the traditional database models, such as the 
table structure of the relational database, with its rigid rows 
and columns, or records and fields. 
Although the field, record and update objects do not 

50 actually exist in table form in the preferred embodiment, an 
"embedded table" format 260 can be used to describe the 
concepts of the present system. 

Referring to FIG. 4, a collection of field objects can be 
depicted as a "table." The column headings are field type, 

55 field length and field value. The rows identify a particular 
item of data. This "table" exists embedded within a record 
object. 

A collection of record objects can be depicted as another 
"table," with the column headings of record type, unique 

60 record identifier and collection of field objects "table." Each 
row is a single record object. This collection of records 
"table" can be embedded in the overall database "table." 

A collection of update objects can be depicted as another 
"table," with the column headings of: update length 241, 

65 unique patient identifier 242, unique update object identifier 
243, a record object "table" containing its collection of field 
objects "table" 220, identification tags of intended destina- 
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tions 244, update type identifiers 245, acknowledgment flags nicate through the controller module with the rest of the 

246 and audit fields 247. Each row is a single update object. system, while concurrently sending displays to the presen- 

This collection of updates "table" can be embedded in the tation manager for the station operator to view. A separate 

overall database "table," just the same as the collection of view module 113 is provided for that purpose, 

records "table." 5 Information appropriate for presentation to the station 

The database "table" has column headings of unique operator is selected from the controller module and the data 

patient identifier, collection of records "table" and collection model generation module, assembled into the appropriate 

of updates "table." Each row contains the entire medical file and ^mittedto the presentation manager of the 

of a particular patient operating system 115. The presently preferred embodiment 

As mentioned previously, in the present embodiment, the 10 °P eratcs in a fofl y fas Won, so that the controller 

administrative services system also contains a relational modulc and thc data g cnerat)on modulc can construct data 

database and a database conversion system for coupling the ob J ects > communicate with the PDC and handle data routing 

object-oriented and the relational databases. and u P datin S factions while the view module concurrently 

The purpose of the relational database is to include its * formatlon to « tatlon °P erator - 

generally known management and administrative advan- 15 This offers an important advantage in the present embodi- 

tages in the present system. mcnt bec . aus f communication with the station operator and 

communication with the PDC are typically the lowest 

IV Technical Structure throughput links in the system. The present configuration 

See FIG. 6. takes advantage of this arrangement, allowing many data 

A Portable Data Carrier 100 2 o P roce ssing tasks to be performed concurrently while the 

The presently preferred portable data carrier is a micro- SYstcm is rcadin g and writin S to the PDC and also whilc the 

processor and memory-based smart card, that conceptually station operator is interacting with the system through the 

has four principle subsystems: a communication manager user scrceD - D"™^ tyP lcal operation, the station operator 

101, a file manager 102, a file system (database) 103 and a can interact ™& me user ^putting information 

security manager 104. 25 about t * ie P at i enl > or a bout the diagnosis or procedures to be 

The invention is designed to use the smart card command performed, without noticing any degradation in system 

set by which commands are input and output through the performance as the PDC is concurrently being read and 

serial communication port via the communication manager. updated. 

Smart card requests include security requests and file ( 2 ) The pos database manager 116 controls access to the 

requests which are directed to the security manager and file 30 database. It contains: a record object manager 117, an 

manager respectively. The file manager will not allow update object manager 118, a data engine 119, an index 

memory read/write operations to the internal file system engine 120 and codes tables subsystem 121. 

database unless authorized by the security manager. Autho- The mdcx engine coupled to the data engine provides 

rizations are the result of bi-directional communications ac cess to the database. As mentioned previously, the access 

between the security manager and the file manager. 35 is via serial numbers, demographic information, code 

In the presently preferred embodiment, all patient infor- numbers, data type and the like, 

mation data is stored as a collection of record objects in the The data engine 119 controls the storage and retrieval of 

file system database. Although other structures are possible, data from m e database storage subsystem. The data engine 

the present system utilizes electronically erasable program- ^ coupled to both the record object manager 117 and the 

mable read-only memory (EEPROM), because of its ability 40 u P date ob i ect manager 118. Collectively, these two object 

to retain information even when external power is turned off. managers contain the rule sets by which medical information 

B Point-of-service Stations 110 objects are processed according to the processing tags 

In the presently preferred embodiment, the subsystems of embedded within the data objects, 

the POS stations are: the user interface 111, the database The codes table subsystem 121 can contain numerous 

manager 116, the database 122, the patient manager 123, the 45 types of codified information. The present system includes 

PDC manager 124, the communication manager 128. standard medical CPT and ICD-9 code tables, as well as fists 

(1) The user interface 111 generates and initiates the of authorized physicians and list of authorized medications, 

propagation of record objects and update objects. It 0) The POS database 122 is object-oriented. It is flexible 

also generates the user display screens that the POS m ^ zc - 14 storcs and retrieves data according to key 

station operator sees. 50 identifiers, which include unique patient serial 

The user interface contains: a controller module 112, a numbers, demographic information, code numbers and 

view module 113 and a data model generation module 114. data type. Data is stored as collections of record objects 

It accesses the system graphical interface of the operating 230 (F lG - 3 ) and as collections of update objects 250 

system 115. (FIG. 4). 

The controller module 112 responds to the PDC presence 55 (4) The patient manager 123 is the coordinator of the POS 

signals transmitted to it and initiates the user interface's station. It communicates with the user interface 111, the 

response to the PDC's presence. It is also the principle database manager 116, the PDC manager 124 and the 

connection to the presentation manager of the operating communication manager 128. It contains major rule 

system. sets relating to data processing, such as routing update 

The data model generation module 114 constructs the 60 objects and modifying databases. These rule sets will 

record objects and update objects with the appropriate tags be described later. 

attached, sends the update object to the controller module, (5) The PDC manager 124, contains; a PDC presence 

which then transmits the update object to the rest of the monitor 125 and a PDC database manager 126. 

system. The PDC presence monitor detects the presence of a PDC 

In the presently preferred embodiment, much of the 65 when it is installed in the read/write port, 

processing that takes place within the user interface is The PDC database manager handles access and security 

invisible to the user. The user interface is able to commu- functions. It assures that the PDC conforms to the physical 
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specifications of the system and that the PDC is not fraudu- 
lent or defective. It also copies the record objects from the 
PDC database. It then retrieves any update objects that are 
stored in the POS database and applies these updates to the 
PDC collection of records, thus making the PDC records the 
most current in the system. Copies of this updated collection 
of records are then sent to both the PDC and the POS 
databases. 

In order to save space and time, the PDC database 
manager performs the necessary processing steps to deter- 
mine which fields need to be updated, so that only those 
fields arc written to the PDC. 

The PDC database manager is resident within the POS 
station and has greater throughput capacity than the PDC. 
While selective updating of the PDC is presently preferred 
for throughput reasons, the invention can be implemented in 
alternate ways, such as downloading a complete copy of the 
updated collection of records. 

(6) The communication manager 128 controls the POS 
station's bidirectional communication with the switch- 
ing station. In the presently preferred embodiment, this 
communication takes place using asynchronous 
modems, although any standard communication system 
could be used. The communicated data is encrypted for 
security purposes. The communication manager 128 is 
able to both initiate and receive calls over a commu- 
nication channel. 
The communication manager interacts with the applica- 
tion layer 129, that is in turn connected to the successive 
layers of the open system's OSI architecture, namely pre- 
sentation layer 130, session layer 131, transport layer 132, 
network layer 133, physical 134 and data link 135 layers. 
These layers ultimately communicate with the transmission 
medium. 

C Switching Station 140 

In the presently preferred embodiment, the switching 
station provides a conduit for keeping the various indepen- 
dent databases current. It contains rule sets for routing 
update objects between POS stations, according to the 
routing tags contained in the update objects. This is an 
alternate communication channel to the PDC-POS connec- 
tion and may be utilized when the PDC is not directly 
available as the data transport medium. 

In the present system, the switching station temporarily 
stores a local copy of each update object that it transmits. 
The local copy remains in memory at the switching station 
until aU destination POS stations have acknowledged suc- 
cessful receipt of the update object. It is then deleted from 
the switching station memory. 

In this embodiment, the switching station also sends a 
copy of each update object to the administrative services 
system. Although this connection provides access to some 
administrative services, such as data backup, auditing and 
billing, the integrity of the network does not depend on this 
connection. The system functions well without needing to 
access a masterfile. 

In the presently preferred embodiment, the switching 
station contains two subsystems: a communication manager 
141 and an update manager 142. 

The communication manager 111 is configured to com- 
municate bidirectionally with each POS station. In the 
present embodiment, this is achieved via asynchronous 
modems, although other communication channels are pos- 
sible. For security purposes, the transmitted data is 
encrypted. The communication manager 141 is able to both 
initate and receive calls over the communication channel. 

The communication manager also handles bidirectional 
communication with the administrative services system. 
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Local or wide area networks can both be utilized depending 
on the geographic distribution of the system. In the present 
embodiment, TCP/IP protocol is used with ISDN and eth- 
eraet connections. Other protocols and connections can 

5 certainly be used. 

The update manager 142 contains the rule sets for routing 
update objects between POS stations. Although it can be 
configured otherwise, in the present embodiment, the POS 
station of the patient's primary physician and the adminis- 

5Q trative services system both receive a copy of every update 
object pertaining to that patient. Copies of an update object 
are also sent to the ordering physician and to other various 
POS stations as may be designated on the update objects 
destination tags. 

For example, when a consultant physician orders a labo- 

15 ratory test, the patient goes to the laboratory and has the test 
performed. The laboratory's POS station generates the 
update object containing the result of the test. That update 
object is: (1) stored in the laboratory's database and (2) 
transmitted to the switching station. From the switching 

20 station, it goes to: (3) the consultant physician's office, (4) 
the primary physician's office and (5) the administrative 
services station. From the primary physician's oifice or the 
consultant's office, the result is transmitted to: (6) the 
patient's PDC. 

25 In this example, when the above process has been 
completed, the test result will have been successfully and 
automatically propagated to six independent locations, with- 
out needing to access a central database or masterfile, and 
without requiring the POS stations to be physically con- 

30 nected to each other. 

Furthermore, the update object remains "alive" in the 
system, until assurances, in the form of acknowledgments, 
have been received, indicating that the record object it 
contains has successfully reached all of its designated data- 

35 bases. 

D Administrative Services System 150 

In the presently preferred embodiment, the administrative 
services system consists of: a communication manager 151, 
an object-oriented database 152, a database conversion 
40 system 153, a commercially available relational database 
154 and "customer" services 155. 

(1) The communication manager 151 controls communi- 
cation with the switching station as described above. 
Direct communication between the administrative ser- 

45 vices system and the POS stations is possible, but is not 
presently configured, mainly for security purposes. 

(2) The presently preferred object-oriented database 152 
is application specific. It is configured according to the 
"embedded table" architecture described previously. It 

50 contains a key patient identifier, collections of record 
objects and collections of update objects. 
It essentially contains a duplication of each of the PDC 
and POS databases, with the added feature that all update 
objects persist here indefinitely, primarily for auditing pur- 
55 poses. 

Although the presently preferred distributed database 
architecture is relatively fail-safe on its own because it 
distributes the data independently throughout the system and 
does not rely on a central station or masterfile, the admin- 
60 istrative services system's database can be used to backup 
the distributed PDC and POS databases when necessary. 

(3) The database conversion system- 153 translates the 
information from the object-oriented structure to a 
relational database structure. This is accomplished by 

65 individually selecting record objects from the object- 
oriented database and depositing them in fixed field and 
record relational tables. 
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(4) In the presently preferred embodiment, a relational 
database architecture, IBM's DB/2, 154 is included to 
accommodate interaction with a plurality of external 
systems and services. 

It allows the present invention to interact easily and 5 
efficiently via widely used standard protocols and query 
languages. It facilitates communication with healthcare 
providers, managers, payers and researchers. It allows the 
present invention to provide services, such as the "cus- 
tomer" services described below, 10 

(5) "Customer" services 155 are the ancillary 
management-type services provided by this system to 
patients, healthcare providers, managers, payers and 
researchers. These services include, but are not limited 
to, data backup, billing, payment, account settlement, 15 
medical and financial auditing, report generation, qual- 
ity control and risk management. 

V Describing Data Flow via Processing Rules 

See FIGS. 7, 8, 9, 10, 11 and 12. 20 
A An Overview of the Processing Rules 

In the presently preferred embodiment, each patient's 
medical file is kept current at numerous independent data- 
bases by routing medical data through the system via update 
objects that interact with strategically placed rule sets. 

The update objects are generated at all POS stations and 
in the administrative services system. 

The general rules for processing update objects are 
located within each POS station, in the switching station and ^ 
in the administrative services system. The general process- 
ing rules, as shown in FIGS. 7 and 8, are distributed as 
follows: 

User Interface 111 

Generate update object 35 
Send update object to patient manager 
Request patient record from this POS database 
Patient Manager 123 

Concurrently update PDC and POS databases 

40 

Bring PDC records up to date 
Send updated PDC records to this POS database 
Get patient records from this POS database for user 
interface 

Propagate update object that was generated in this user 45 
interface 

Add new update object to this station's database 
Store update objects in queue 

Intermittently send update objects to the communication 5Q 
manager 

Send update objects to PDC manager 

Propagate update object that was received from the 

switching station 
Add update object to this station's database 55 
Sort update objects by patient ID 
Sort update objects by type 

Send record objects to this station's database according to 

the above sorting 
Database Manager 116 60 
Add update object to collection of update objects 
Store update objects until acknowledgments are received 
Modify database by adding, deleting, or replacing record 

objects 65 
PDC Manager 124 

Notify patient manager of PDC presence 
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Copy records from the PDC 

Receive updates from this POS station's database 

Apply updates to copy of PDC records 

Send updated records to PDC and this station's database 

Communication Manager 128 

Send update objects to switching station 

Receive update objects from switching station 

Switching Station 140 

Receive update objects from POS stations and adminis- 
trative services system 
Route update objects to designated POS stations 
Route update objects to administrative services system 
Store update objects until acknowledgments are received 
Send update objects to POS stations and administrative 
services system 
B Specific Processing Rules Within a POS Station 

In the present embodiment, within each POS station, each 
update object 240 (FIG. 4) is generated in the user interface 
111. From there, it is routed through the patient manager 123 
to the database manager 116, the PDC manager 124 and the 
communications manager 128. See FIG. 6. This routing is 
accomplished by following the rules which define the inter- 
actions among these various subsystems. 

The rules themselves can be divided into sets based on the 
several different routing functions that the POS station can 
accomplish. These functions are: (1) concurrently updating 
the PDC and POS databases when a PDC is presented for 
service (FIG. 9), (2) propagating an update object that was 
generated in this POS station (FIG. 10) and (3) propagating 
an update object that was received from the switching 
station (FIG. 11). Each of FIGS. 9-11 show, through a series 
of sequentially numbered steps, the order in which the rules 
are implemented. 

(1) Concurrently updating the PDC and POS databases 
when a PDC is presented for service (FIG. 9): 



1 Insert PDC in POS station. 

2 PDC manager copies the records from the PDC. 

3 PDC manager notifies the patient manager that the PDC 
is present. 

4 Patient manager requests updates from the database 
manager. 

5 Database manager sends the updates from the database 
to the patient manager. 

6 Patient manager sends the updates from the database to 
the PDC manager. 

7 PDC manager acknowledges processing of updates from 
the patient manager. 

8 PDC manager applies updates to copy of PDC records, 

9 PDC manager sends updated records to PDC 

10 Patient manager requests patient records from the 
database manager. 

1 1 Database manager sends patient records from the 
database to the patient manager. 

1 2 Patient manager requests the updated patient records 
from the PDC manager. 

13 PDC manager sends the updated patient records to the 
patient manager. 

1 4 The patient manager applies the updated records from 

the PDC manager to the patient records from the database. 

15 Patient manager sends the updated records to the 
database manager. 

1 6 Database manager sends the updated records to the 
database. 

17 Patient manager notifies its "get patient records for 
user interface" section that this station's database 
records have been updated. 

18 PDC manager notifies the user interface that a PDC is 
present. 
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User interface requests the patient records from the 
patient manager. 

Patient manager waits for notification that this 
station's database has been updated. 
Patient manager requests the updated records from the 
database manager. 

Database manager sends the updated records from the 
database to the patient manager. 
Patient manager sends the updated patient records to 
the user interface. 

User interface receives the patient records for 
interface use. 



At the end of this series of transactions, both the PDC 15 
database 103 and the POS database 122 are identical and 
current. The two databases have updated each other; and the 
updated records are ready for use at the user interface 111. 

Since this embodiment utilizes a multitasking operating 
system, the POS station operator can interact with the user 
interface with no perceived delay, while the PDC and POS 
databases are interrogating and updating each other. 



20 



(2) Propagating an update object that was generated at this 
POS station (FIG. 10): 



1 The user interface generates a new update object 

2 The user interface sends the update object to the 
patient manager. 

3 Patient manager routes the update object to three of 
its subsectians; see steps (4), (13) and (16). 

4 The patient manager sends the update object to the 
database manager. 

5 The database manager adds the update object to the 
collection of update objects in the database. 

6 The patient manager sorts the update objects by type 
(add, delete, replace). 

7 The patient manager sends an "add this record object" 
message to the database manager. 

8 The database manager adds the record object to the 
database. 

9 The patient manager sends a "delete this record 
object" message to the database manager. 

10 The database manager deletes the record object from 
the database. 

11 The patient manager sends a "replace this record 
object" to the database manager. 

12 The database manager replaces the record object in the 
database. 

13 The patient manager sends the update object to the PDC 
manager. 

14 The PDC manager applies the updates to the PDC 
manager's copy of the PDC records. 

15 The PDC manager tends the updated records to the PDC 

16 The patient manager stores the update objects until 
they are requested by the communication manager. 

17 The communication manager intermittently requests 
updates from the patient manager. 

18 The patient manager sends update objects to the 
communication manager. 

19 The communication manager sends update objects to the 
switching station. 



At the end of this series of transactions, a new update 
object 240 has been generated, stored in the POS database 
122, transferred to the PDC database 103 and sent to the 
switching station 140. By utilizing a multitasking operating 
system, all of these transactions can essentially occur simul- 
taneously. 

(3) Propagating an update object that was received from 
the switching station (FIG. 11): 



1 The communication manager of the POS station receives 
an update object from the switching station. 

2 The communication manager sends the update object to 
the "apply update objects ta this station's database" 
section of the patient manager.' . 

3 The patient manager sorts the update objects by 
patient identification. 

4 The patient manager sends the update objects to the 
database manager based on patient identification. 

5 The database manager adds the update objects to the 
collection of updates in this station's database based on 
patient identification. 

6 The patient manager sorts the update objects by type 
(add, delete, replace). 

7 The patient manager sends an "add this record object" 
message to the database manager. 

8 The database manager adds the record object to this 
station's database. 

9 The patient manager sends a "delete this record 
object" to the database manager. 

10 The database manager deletes the record object from 
this station's database. 

11 The patient manager sends a "replace this record 
object" to the database manager. 

12 The database manager replaces the record object in 
this station's database. 



25 At the end of this series of transactions, an update object 
240 that has been received from the switching station 140, 
has beeD deposited in this POS station's database 122. The 
database is modified appropriately; and if so designated, the 
update object persists until it is successfully transmitted to a 

30 PDC database 103. 

C Processing Rules for Routing an Update Object Through 
the Entire System (FIG. 12): 

In the present embodiment, each update object is gener- 

35 ated and propagated within a POS station according to the 
above rules. The update object is then routed to the switch- 
ing station for propagation through the rest of the system. 

The switching station acknowledges receipt of every 
update object from each POS station. It then routes all 

40 update objects to the administrative services system. For 
functions such as data backup, system security and auditing, 
a copy of every update object is retained in an administrative 
services database indefinitely. 

45 The switching station also routes each update object to the 
POS stations designated on the update objects destination 
tags. In the present embodiment, all update objects will at 
least be routed to the physician who ordered the procedure 
that generated the update object and to the patient's primary 

50 physician. 

For example, if a consultant physician orders a laboratory 
test, the destination tag on the update object that contains the 
test result will indicate that the update should be sent to that 
55 consultant. The rule set in the switching station will read the 
update object and recognize that the physician who ordered 
the test is a consultant and not the patient's primary physi- 
cian; so it will also route the update object to the primary 
physician. 

60 The switching station stores a copy of each update object 
until it receives an acknowledgment from each of the 
destination POS stations that the update object has been 
successfully received. When all acknowledgments have 
been received, the update object is deleted from the switch- 
ed ing station. 

The following are the rules that define the propagation of 
an update object through the entire system (FIG. 12): 
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1 The user interface in the initial POS station 
generates an update object. 

2 The user interface sends the update object to the 
patient manager. 

3 The patient manager routes all update objects and 
acknowledgments. 

4 The patient manager sends the update object to the 
database manager. 

5 The database manager sends the update object to the 
database. 

6 The collection of record objects within the database 
is updated. 

7 The update object is temporarily stored until all 
acknowledgments are received. 

8 The patient manager sends the update object to the PDC 
manager. 

9 The PDC manager sends an acknowledgment (A) to the 
patient manager that it has received the update. 

10 The patient manager sends that acknowledgment (A) to 
the database manager. 

11 The database manager sends that acknowledgment (A) to 
the update object in the database. 

12 The PDC manager applies the update object to its copy 
of the PDC records. 

13 The PDC manager sends the updated records to the PDC 

14 The patient manager sends the update object to the 
communication manager. 

15 The communicatioa manager sends the update object to 
the switching station. 

3 6 The switching station sends an acknowledgment (B) to 
the communications manager that it received the update. 

17 The communications manager sends that acknowledgment 
(B) to the patient manager. 

18 The patient manager sends that acknowledgment (B) to 
the database manager. 

19 The database manager sends that acknowledgment (B) to 
the update object in the database. 

20 The update object is deleted from the database since 

it has received the appropriate acknowledgments (A) and 
(B> 

21 The switching station sorts the update object 
according to designated POS station destinations. 

22 The switching station stores update objects until all 
acknowledgments have been received. 

23 The switching station sends the update object to 
designated POS stations. 

24 The POS station sends acknowledgment (C) of receipt of 
the update object to the switching station. 

25 The switching station receives the acknowledgment (C). 

26 The POS station updates its own database just like the 
initial POS station. 

27 The POS station stores the update object until all 
acknowledgments have been received. 

28 The POS station updates the PDC database when a PDC is 
presented. 

29 The switching station sends the update object to the 
administrative services system. 

30 The administrative services system sends 
acknowledgment (D) of receipt of the update object to the 
switching station. 

31 The switching station receives acknowledgment (D) from 
the administrative services system. 

32 The update object is deleted from the switching 
station because it has received the appropriate 
acknowledgments (C) and (D). 

33 The administrative services system updates its own 
database. 



At the end of this series of events, the patient's PDC 
database 103, as well as all designated POS databases 122 
and the administrative services system database 150 are all fi0 
synchronized and current. See FIG. 6. All record objects 220 
(FIG. 3) have been deposited appropriately and acknowl- 
edged. All update objects 240 (HG. 4) have been deleted 
from the system. And this has all been accomplished without 
needing to access a masterfile. 

We claim: 65 
1. A computer system for maintaining the currency of data 
in distributed databases, comprising: 



a data communication network; 

a plurality of physically separate databases, each of said 
databases including means for communicating with 
said data communication network, said databases col- 
lectively defining said distributed databases; 

a processor having interface for supplying an input 
instruction to modify the contents of the distributed 
databases; 

said processor being coupled to said data communication 
network; 

said processor being operable to generate an update object 
in response to said instruction and to place said update 
object in said data communication network; 

said update object having a self-contained processing tag 
for causing said update object to be intelligently routed 
along said data communication network to at least one 
of said plurality of databases and for causing said one 
of said plurality of databases to automatically modify 
its contents in accordance with said input instruction; 

said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated withio said 
record objects and wherein said record objects encap- 
sulated within said update object; 

said update object thereby being configured to automati- 
cally store data and to automatically store in said 
attributes an historic record of processes performed on 
said data as said update object is ranted anywhere 
throughout said communication network. 

2. The system of claim 1 wherein said data communica- 
tion network comprises a system employing a portable data 
carrier having memory for storing and transferring data 
among said plurality of databases. 

3. The system of claim 1 wherein said data communica- 
tion network comprises a telecommunication network. 

4. The system of claim 1 wherein said data communica- 
tion network comprises in combination: 

a system employing a portable data carrier having 
memory for storing and transferring data among said 
plurality of databases; and 

a telecommunication network. 

5. The system of claim 1 wherein said data communica- 
tion network is coupled to a routing processor responsive to 
said processing tag in intelligently routing said update object 
along said data communication network. 

6. The system of claim 1 wherein said processing tag of 
said update object comprises a data structure for storing a 
destination datum for causing said update object to be 
intelligently routed along said data communication network. 

7. The system of claim 1 wherein said data communica- 
tion network is coupled to a routing processor and wherein 
said processing tag of said update object comprises a data 
structure for storing a destination datum that is accessed by 
said routing processor in causing said update object to be 
intelligently routed along said data communication network. 

8. The system of claim 1 wherein at least one of said 
databases includes a database processor responsive to said 
processing tag in modifying the contents of its database. 



WEST 



5,8! 

21 

9. The system of claim 1 wherein said processing tag of 
said update object comprises a data structure for storing an 
operation datum based on said input instruction for use in 
automatically modifying the contents of at least one of said 
databases. 

10. The system of claim 1 wherein at least one of said 
databases includes a database processor and wherein said 
processing tag of said update object comprises a data 
structure for storing an operation datum based on said input 
instruction that is accessed by said database processor in 
modifying the contents of said one of said databases. 

11. The system of claim 1 wherein said data communi- 
cation network is coupled to a routing processor having an 
associated memory for storing a routing rules set. 

12. The system of claim 1 wherein said processing tag of 
said update object comprises a data structure for storing a 
destination datum that is used according to predefined rules 
to cause said update object to be intelligently routed along 
said data communication networks. 

13. The system of claim 1 wherein said processing tag of 
said update object comprises a data structure for storing a 
destination datum that is used according to predefined rules 
to cause said update object to be intelligently routed to a 
selected one of said databases. 

14. The system of claim 1 wherein said data communi- 
cation network is coupled to a routing processor having an 
associated memory for storing a routing rules set and 
wherein said processing tag of said update object comprises 
a data structure for storing a destination datum that is 
accessed by said routing processor and used in accordance 
with said routing rules to cause said update object to be 
intelligently routed along said data communication network. 

15. The system of claim 1 wherein said data communi- 
cation network includes a routing processor having an 
associated memory for storing a routing rules set and 
wherein said processing tag of said update object comprises 
a data structure for storing a destination datum that is used 
according to said routing rules to cause said update object to 
be intelligently routed to a selected one of said databases. 

16. The system of claim 1 wherein at least one of said 
databases includes a database processor and an associated 
memory for storing an operation processing rules set. 

17. The system of claim 1 wherein said processing tag of 
said update object comprises a data structure for storing an 
operation datum based on said input instruction that is used 
according to predefined rules to automatically modify the 
contents of at least one of said databases. 

18. The system of claim 1 wherein at least one of said 
databases includes a database processor and an associated 
memory for storing an operation processing rules set and 
wherein said processing tag of said update object comprises 
a data structure for storing an operation datum based on said 
input instruction that is accessed by said database processor 
and used in accordance with said operation processing rules 
to automatically modify the contents of at least one of said 
databases. 

19. The system of claim 1 wherein said data communi- 
cation network includes a routing processor having an 
associated memory for storing a routing rules set and 
wherein said processing tag of said update object comprises 
a data structure for storing a destination datum that is 
accessed by- said routing processor and used in accordance 
with said routing rules to cause said update object to be 
intelligently routed to at least a selected one of said 
databases, and 

wherein at least said selected one of said databases 
includes a database processor and an associated 



19,998 

22 

memory for storing an operation processing rules set 
and wherein said processing tag of said update object 
comprises a data structure for storing an operation 
datum based on said input instruction that is accessed 
5 by said database processor and used in accordance with 
said operation processing rules to automatically modify 
the contents of said selected one of said databases. 

20. A computer-implemented method of maintaining the 
currency of data in distributed databases consisting of a 

10 plurality of physically separate databases, comprising: 

receiving an input instruction corresponding to a request 

to modify data in said distributed databases; 
using said input instruction to generate an update object 
that includes a self-contained processing tag; 

35 said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 

20 objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
data stmcture defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update object; 
said update object thereby being configured to automati- 
cally store data and to automatically store in said 

30 attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
throughout said communication network; 
conveying said update object to at least a selected one of 
said plurality of databases using said processing tag to 

35 cause said update object to be intelligently routed to 
said selected one of said databases; 
further using said processing tag to cause said selected 
one of said databases to automatically modify its 
respective contents in accordance with said input 

40 instruction. 

21. The method of claim 20 further comprising employing 
a portable data carrier to convey said update object by 
storing the contents of said update object in said portable 
data carrier and physically transporting said portable data 

45 carrier between said selected databases. 

22. The method of claim 20 further comprising using a 
telecommunication network to transmit said update object 
between said selected databases. 

23. The method of claim 20 further comprising using a 
50 data communication network that employs, in combination, 

a portable data carrier and a telecommunication network and 
wherein said conveying step is performed by at least one of 
the following methods: 

(a) by storing said update object in said portable data 
55 carrier and physically transporting said portable data 

carrier between said databases and 

(b) by transmitting said update object over said telecom- 
munication network. 

24. The method of claim 20 wherein at least a first one of 
60 said plurality of databases has an associated processor and 

wherein said method further comprises using said associated 
processor to write to a processing tag a datum indicative of 
a destination database to which the update object is intelli- 
gently routed. 

65 25. The method of claim 20 wherein at least a first one of 
said plurality of databases has an associated processor and 
wherein said method further comprises using said associated 
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processor to write to a processing tag a datum to specify a 
selected one of a plurality of data manipulation processes. 

26. The method of claim 20 wherein at least a first one of 
said plurality of databases has an associated processor and 
wherein said method further comprises using said associated 5 
processor to read said processing tag and to intelligently 
route said update object to a second one of said plurality of 
databases in accordance with said processing tag. 

27. The method of claim 20 wherein at least a first one of 
said plurality of databases has an associated processor and 10 
wherein said method further comprises using said associated 
processor to read said processing tag and to route said update 
object to a communication network. 

28. The method of claim 20 wherein at least a first one of 
said plurality of databases has an associated processor and 15 
wherein said method further comprises using said associated 
processor to read said processing tag and to route said update 
object to a routing processor coupled to a communication 
network. 

29. The method of claim 20 wherein at least a first one of 20 
said plurality of databases has an associated processor and 
wherein said method further comprises using said associated 
processor to read said processing tag and to modify the 
contents of said first database in accordance with said 
processing tag. 25 

30. The method of claim 20 further comprising conveying 
said update object over a data communication network to a 
routing processor. 

31. The method of claim 20 further comprising: 
conveying said update object over a data communication 30 

network to a routing processor; and 
using said routing processor to route said update object to 
at least a second one of said plurality of databases over 
said data communication network. 

32. The method of claim 20 wherein at least a first one of 35 
said databases includes an associated processor and wherein 
said method further comprises storing a routing rules set in 

a memory addressed by said associated processor and using 
associated processor to access said routing rules set and said 
processing tag to cause said update object to be routed along 40 
said data communication network. 

33. The method of claim 20 wherein said data commu- 
nication network includes an associated processor and 
wherein said method further comprises storing a routing 
rules set in a memory addressed by said associated processor 45 
and using said associated processor to access said routing 
rules set and said processing tag to cause said update object 

to be intelligently routed to a destination database. 

34. The method of claim 20 wherein at least a first one of 
said plurality of databases has an associated processor and 50 
wherein said method further comprises storing an operation 
processing rules set in a memory addressed by said associ- 
ated processor and using said associated processor to access 
said rules set and said processing tag and to modify the 
contents of said first database. 55 

35. An information system for maintaining the currency 
of computerized records, comprising: 

a first processor with associated first memory for storing 
a first database of computerized records; 6Q 

a second processor with second memory for storing a 
second database of computerized records; 

said first and second memories being disposed at physi- 
cally separate locations; 

a smart card having an embedded third processor and 65 
associated third memory for storing a third database of 
computerized records; 
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said first and second processors each having a port for 

interfacing with said smart card; 
said smart card being: 

operable as a client and server to said first and second 
databases; 

physically transportable between said first and second 
databases; and 

operable to propagate information between said first and 
second databases such that the currency of computer- 
ized records is maintained in said first, second and third 
databases; 

wherein said first processor generates an update object for 
routing an element of information to said second data- 
base; 

said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update object; 

said update object thereby being configured to automati- 
cally store data and to automatically store in said 
attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
throughout said communication network. 

36. The information system of claim 35 wherein at least 
one of said first and third processors operate on both first and 
third databases to mutually update both first and third 
databases. 

37. The information system of claim 35 wherein at least 
one of said second and third processors operate on both 
second and third databases to mutually update both second 
and third databases. 

38. The information system of claim 35 wherein at least 
one of said processors generates an update object carried by 
said smart card. 

39. The information system of claim 35 wherein said first 
processor generates an update object for routing an element 
of information to said second database, said update object 
including a processing tag to identify at least a selected one 
of a plurality of data processing operations; and 

wherein said second processor operates on the comput- 
erized records stored in said second database using said 
element of information in accordance with said pro- 
cessing tag. 

40. A self -updating computer-implemented database sys- 
tem for storing elements of information comprising: 

a computer-implemented system for generating an update 
object that stores an element of information and that 
includes a processing tag for specifying at least one of 
a plurality of predefined data manipulation processes 
and for causing said update object to be intelligently 
routed to at least one destination; 
. a second database with associated second processor for 
receiving said update object; 

a second database with associated second processor for 
receiving said update object; 

said update object further having an object-oriented data 
structure that defines independently created field 
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objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 5 
ma tion independent of said distributed databases, said 
data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update object; J0 

said update object thereby being configured to automati- 
cally store data and to automatically store in *said 
attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
throughout said communication network, 5 

said first processor being responsive to the processing tag 
of said update object to: 

(a) modify the contents of said first database in accor- 
dance with the data manipulation process specified 
by said processing tag; 20 

(b) store said update object in said first database; and 

(c) convey said update object to said second database in 
accordance with the destination specified by said 
processing tag; 

said second processor being operative to: 25 

(i) modify the contents of said second database in 
accordance with the data manipulation process 
specified by said processing tag; and 

(ii) send an acknowledgment of receipt of said 
update object to said first processor; 30 

said first processor being operative to initiate deletion of 
said update object from said first database in response 
to receipt of said acknowledgment from said second 
processor. 

41. The system of claim 40 wherein said computer- 35 
implemented system generates said update object in 
response to input from a user of said database system. 

42. The system of claim 40 wherein said second processor 
is further operative to store said update object in said second 
database. 40 

43. The system of claim 40 wherein the system includes 
a third database with associated third processor and wherein 
said second processor is further operative to convey said 
update object to said third processor. 

44. The system of claim 40 further comprising a data 45 
communication network and wherein said first processor 
conveys said update object to said second processor over 
said communication network. 

45. The system of claim 44 wherein said data communi- 
cation network comprises a system employing a portable 50 
data carrier having memory for storing said update object. 

46. The system of claim 44 wherein said data communi- 
cation network comprises a telecommunication network. 

47. The system of claim 44 wherein said data communi- 
cation network comprises in combination: 55 

a system employing a portable data carrier having 
memory for storing said update object; and a telecom- 
munication network. 

48. The system of claim 44 wherein said data communi- 
cation network is coupled to a routing processor for reading 60 
said processing tag and conveying said update object to at 
least said second database. 

49. The system of claim 40 wherein said first and second 
databases are disposed at physically separate locations. 

50. The system of claim 40 wherein said update object 65 
includes means for storing an identification datum that 
functions as a database key. 



51. An information system for maintaining the currency 
of computerized records, comprising: 

a first processor with associated first database of comput- 
erized records; 
a second processor with associated second database of 

computerized records; 
said first and second databases being disposed at physi- 
cally separate locations; 
a portable data carrier having a third processor and 

associated third database of computerized records; 
said first and second processors each having a port for 

interfacing with said portable data carrier; 
said portable data carrier being operable as a client and 
server to said first and second databases and physically 
transportable being said first and second processors to 
define a first communication channel that is operable to 
propagate information between said first and second 
databases; 

at least one of said first and second processors having a 
routing rules set forth for causing at least one of said 
first and second processors to propagate information 
between said first and second databases over a second 
communication channel; 
whereby said first and second communication channels 
collectively operate such that currency of computerized 
records is maintained in said first, second and third 
databases; 

wherein said first processor generates an update object 
that is propagated over at least one of said first and 
second communication channels; 
said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update object; 
said update object thereby being configured to automati- 
cally store data and to automatically store in said 
attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
throughout said communication network. 

52. The information system of claim 51 wherein said 
portable data carrier is a smart card that includes said third 
processor and said third database. 

53. The information system of claim 51 wherein the first 
database stores an update object containing a database 
modification processing tag; 

wherein at least one of the first and third processors causes 
at least one of the first and third databases to be initially 
modified according to the processing tag and then at 
least one of the first and third processors updates the 
other of said first and third databases based on the 
information in said initially modified database; 
and wherein at least one of the second and third proces- 
sors updates the second database based on the infor- 
mation contained in third database upon the portable 
data carrier being physically transported to said second 
database. 

54. The information system of claim 51 wherein the first 
processor generates an update object containing a routing 
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tag and database modification tag, the first processor stores 
the update object in the first database and sends the update 
object along said second communication channel to the 
second processor based on said routing tag and said second 
processor modifies the second database based on said data- 
base modification tag. 

55. The information system of claim 51 wherein said first 
processor has a processing rules set accessed by said first 
processor to generate an update object for routing an ele- 
ment of information to said second database. 

56. The information system of claim 51 wherein said first 
processor has a first processing rules set accessed by said 
first processor to generate an update object for routing an 
element of information to said second database, said update 
object including a processing tag to identify at least a 
selected one of a plurality of data processing operations; and 

wherein said second processor has a second processing 
rules set accessed by said second processor to cause 
said second processor to operate on the computerized 
records stored in said second database using said ele- 
ment of information in accordance with said processing 
tag. 

57. The information system of claim 51 wherein said 
second database includes an administrative services system. 

58. An information system for maintaining the currency 
of computerized records in distributed databases, compris- 
ing: 

a first database with associated first processor; 

a second database with associated second processor; 

said first and second databases being disposed at physi- 
cally separate locations; 

a first communication channel comprising a portable data 
carrier having a third database with associated third 
processor, the portable data carrier being operable as a 
client and server to said first and second databases and 
physically transportable between said first and second 
processors to propagate information between said first 
and second databases; 

a second communication channel accessible by said first 
and second processors; 

a first system for collectively updating said first, second 
and third databases, wherein: 

(a) at least one of said first and third processors is 
operable to mutually update said first and third 
databases; and 

(b) at least one of said second and third processors is 
operable to mutually update said second and third 
databases; 

a second system for collectively updating said first and 
second databases, wherein: 

(a) said first processor generates an update object 
having a processing tag for specifying at least one of 
a plurality of predefined data manipulation processes 
and for specifying at least one destination; 
said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update object; 
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said update object thereby being configured to automati- 
cally store data and to automatically store in said 
attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
5 throughout said communication network, 

(b) said first processor modifies the contents of said first 
database in accordance with the data manipulation 
process specified by said processing tag; 

(c) said first processor propagates said update object to 
io said second processor along said second communi- 
cation channel in accordance with the destination 
specified by said processing tag; 

(d) said second processor modifies the contents of said 
second database in accordance with the data raanipu- 

15 lation process specified by said processing tag; 

whereby the currency of computerized records in said 
first, second and third databases are maintained current. 

59. The system of claim 58 wherein said portable data 
carrier is a smart card that includes said third processor aod 

20 said third database. 

60. The information system of claim 58 wherein said first 
processor includes a user interface and wherein said first 
processor generates said update object based on information 
supplied through said user interface. 

61. The information system of claim 58 wherein the first 
database stores an update object containing a database 
modification processing tag; 

wherein at least one of the first and third processors causes 
at least one of said first and third databases to be 
initially modified according to the database modifica- 
tion processing tag and then at least one of the first and 
third processors updates the first database based on the 
information in the initially modified database; 
and wherein at least one of the second and third proces- 
sors updates the second database based on the infor- 
mation in the third database, upon the portable data 
carrier being physically transported to said second 
database. 

62. The information system of claim 58 wherein the first 
processor generates an update object containing a routing 
tag and database modification tag, the first processor stores 
the update object in the first database and sends the update 
object along at least one of said first and second communi- 
cation channels to the second processor based on said 
routing tag and said second processor modifies the second 
database based on said database modification tag. 

63. The information system of claim 58 wherein said 
second database includes an administrative services system. 

64. A self-updating, computer-implemented distributed 
database system for storing elements of information com- 
prising: 

a computer system for generating and storing data objects 
that include: 

(a) a record object for storing an element of informa- 
tion; 

(b) an update object for defining a relationship with at 
least one associated record object, said update object 
storing a processing tag; 

said update object further having an object-oriented data 
structure that defines independently created field 
objects and record objects, said field objects and said 
field objects each having stored attributes that record 
information about processes performed on those 
objects; 

said data structure encapsulating data for storing infor- 
mation independent of said distributed databases, said 
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data structure defining a nested, hierarchial relationship 
such that said field objects are encapsulated within said 
record objects and wherein said record objects encap- 
sulated within said update objects; 

said update object thereby being configured to automati- 
cally store data and to automatically store in said 
attributes an historic record of processes performed on 
said data as said update object is routed anywhere 
throughout said communication network, 

said computer system further generating a database sys- 
tem that comprises a collection of record objects that 
define a persistent portion of the database and a col- 
lection of update objects that define a transient portion 
of the database; 

the database system being responsive to said processing 
tag for automatically updating the persistent portion of 
said database; 

the database system further including a feedback mecha- 
nism comprising a second update object for systemati- 
cally purging said update objects from the transient 
portion of the database. 

65. The database system of claim 64 wherein said record 
object includes a field object for storing said element of 
information. 

66. The database system of claim 64 wherein said update 
object includes an acknowledgement tag accessed by said 
feedback mechanism in purging said update objects from the 
transient portion of the database. 

67. The database system of claim 64 wherein said pro- 
cessing tag comprises a routing tag and a database modifi- 
cation tag. 

68. The database system of claim 64 wherein said record 
object includes a record identification tag. 

69. The database system of claim 64 wherein at least one 
of said record objects and said update objects employs a 
variable length data storage mechanism. 

70. The database system of claim 69 wherein said variable 
length storage mechanism uses a pointer system for data 
storage and retrieval. 

71. The database system of claim 64 wherein said data- 
base system includes a first database having a first processor 
and wherein said feedback mechanism uses said first pro- 
cessor to read the processing tag of said update object and 
to store said update object in the transient portion of the first 
database. 
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72. The database system of claim 64 wherein said data- 
base system includes a first database having a first processor 
and a second database having a second processor and 
wherein said feedback mechanism uses said first processor 

5 to read the processing tag of said update object and to route 
said update object to said second database in accordance 
with said processing tag. 

73. The database system of claim 64 wherein said data- 
base system includes a first database having a first processor 

30 and a second database having a second processor and 
wherein said feedback mechanism uses said second proces- 
sor to generate a second update object having a second 
processing tag. 

35 74. The database system of claim 73 wherein said second 
processing tag is an acknowledgement tag. 

75. The database system of claim 64 wherein said data- 
base system includes a first database having a first processor 
and a second database having a second processor and 

20 wherein said feedback mechanism uses said second proces- 
sor to transmit a second update object having second pro- 
cessing tag to said first processor. 

76. The database system of claim 64 wherein said data- 
base system includes a first database having a first processor 

25 and a second database having a second processor; 

wherein said feedback mechanism uses said first proces- 
sor to read the processing tag of a first update object 
and to store said first update object in the transient 
portion of the first database; 

30 wherein said feedback mechanism uses said first proces- 
sor to transmit said first update object to said second 
processor; 

wherein said feedback mechanism uses said second pro- 
35 cessor to transmit a second update object having a 
second processing tag to said first processor in response 
to said first update object; and 
wherein said feedback mechanism uses said first proces- 
sor to read said second processing tag and to modify 
40 said first database by deleting said first update object 
from said first database in response to said second 
processing tag. 

***** 
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SYSTEM AND METHOD FOR IMPROVING ensures that a treating physician will be aware of all medi- 

COMPLIANCE OF A MEDICAL REGIMEN cations that a patient may be taking, that informs the treating 

physician of possible drug interactions or drug dosage and 

This is a continuation-in-part of U.S. application Ser. No. administering duration that are outside of recommended 

08/766,584, filed Dec. 12, 1996 now U.S. Pat. No. 5,950, 5 ranges, that permits contacting the patient when his medi- 

630. cation is due regardless of where the patient may be located 

RArFruniTwri nr? tod iiyj\n?vrrroKT at ^ moment > that assists the treating physician in pre- 

BACKGROUND OF THE INVENTION scriWng not Qnly ^ bc&{ mcdication> b * ^ a dosag / and 

1. Field of the Invention duration that is within recommended ranges, as well as a 
This invention relates in general to a system and method 10 system that streamlines the number of medications that the 

to facilitate compliance with a prescribed medical regimen patient is taking, and that incorporates automatic mail 

and ensure integrity of the prescribed medical regimen, and ordering, billing, and other business aspects of prescribing a 

more particularly, to a system and method to monitor the medical regimen. 

patient usage of drugs prescribed by the patient's physician nmvrr* a Km cnyuAPv nc tub 

and to verify that a prescription meets reasonable standards « OBJECTS AND SUMMARY OF THE 

for the drug involved. INVENTION 

2. Prior Art Therefore, one object of this invention is to provide a 
Noncompliance with a prescribed medical regimen, espe- system which better addresses the causes contributing to the 

cially the inaccurate use of prescription drugs, is one of the inaccurate use of prescription drugs and reducing noncom- 

main reasons for most outpatient treatment failure, as well as 20 Prance by a patient of the medical regimen prescribed for 

a cause of serious, life threatening medical complications. ^ c P at i ent < 

The seriousness of the problem has been long recognized Another object of this invention is to provide a system that 
by the medical community. Numerous studies have been identifies for the treating physician possible dosing, admin- 
undertaken in an effort to identify the causes of noncompli- ^ istering duration, or drug interaction problems that might 
ance of a medication regimen. Various causes identified by result from a prescribed medication regimen, 
these studies include forgetfulness, number of medications Another object of this invention is to provide a system that 
prescribed, unclear instructions or a lack of written has the ability to assist the treating physician in prescribing 
instructions, side effects of the medication, cost of the the best medical regimen for the patient and not merely the 
medication, inconvenient or complex dosing schedules, lack 30 most convenient. 

of a primary health care physician, or lack of prescribed A further object of this invention is to provide a system 

medication information given by the primary health care that enables the treating physician to streamline the number 

physician. 0 f me dj C ations j Q a medical regimen, as well as to reduce 

In attempts to overcome one or more of these causes, polypharmacy problems, 

various equipment and systems have been devised. 35 Still another object of this invention is to provide a system 

f,X" of L sl ! ch svstcms can bc sccn in us Pat - No. that has the ability to contact patients no matter where they 

4,695,954 which combines a special drug dispenser to be m ay be located at a particular time. 

patients are automatically contacted by automatic telephone A , . , . * . 

dialing and voice synthesizing equipment to remind them ^^^J ? f 15 * pr ° Vlde . ,? 

that their prescriptions need to be refilled. U.S. Pat. No. SyStCm haS the ablllty t0 tJmely remmd P atients t0 refiU 

5,390,238 discloses a system linking the physician, prescriptions. 

pharmacists, patient, and care provider for the purpose of 45 Another object of this invention is to provide a system that 

monitoring medication usage and patient wellness. assists m the ordering of prescription refills in a manner that 

However, the various prior art systems have proven to be rcduces costs to the entity paying for the prescriptions, 

workable only in controlled environments. Even then they A still further object of this invention is to provide a 

leave unsolved many of the numerous other causes of system that can generate reports useful to the treating 
noncompliance. 50 physician, the patient, the medication provider, and the 

A second problem relating to medical regimens is lack of medication regimen payment source, 

easy checking procedures to determine if a prescription Another object of this invention is to provide a system that 

complies with a recommended regimen. Currently, the U.S. assists in improving the communication between the treating 

FDA publishes a Generic Product Identifier (GPI) which is physician and the patient, in notifying the patient of upcom- 

a listing of available drugs coded by their generic chemical 55 i°g appointments, and in specifying procedures in the medi- 

composition and a National Drug Code (NDC) which is a ca l regimen that the patient should follow, 

listing of available drugs coded by their trade names. Other objects and advantages of the invention will 

However, neither the GPI nor the NDC contain drug reaction become apparent from the ensuing descriptions of the inven- 

information. There does exist a collection of studies which tion. 

describe known reactions for certain drugs. This collection 6 o Accordingly, a system to facilitate compliance with a 

of studies is referred to herein as the Knowledge Base Drug prescribed medical regimen is provided, which comprises a 

Code (KDC). In addition, there are other studies which have computer system having a data storage unit containing 

established classes based on composition of the components stored pharmaceutical data, a central processing unit (CPU) 

which make up a drug. However, a compilation of this programmed and operatively connected to the data storage 

available information has not been assembled for easy use. 65 unit to further store in the data storage unit patient data and 

Thus, there remains in the medical community the need patient prescription data, and an inputting unit operatively 

for a system, and a method of using the system, that better connected to the CPU to transmit patient data and patient 
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prescription data to the CPU, and a reporting unit opera- contrary is given for the purpose of illustration in order that 

lively connected to the CPU; the CPU being further pro- others skilled in the art may fully understand the invention 

grammed to compare the patient data, the patient prescrip- and the principles thereof and the manner of applying it in 

tion data, and the pharmaceutical data to determine if the practical use so that they may modify and adapt it in various 

patient prescription data is within an acceptable medication 5 forms, each as may be best suited to the conditions of a 

dosage range as denned by the pharmaceutical data, and to particular use. 

transmit the determination to the reporting unit FIG. 1 is schematic of an overview of a preferred embodi- 

In a preferred embodiment of the invention, the CPU is ment of the system of this invention, 

further programmed to compare the patient data, the patient FIG. 2 is a schematic of a preferred embodiment of the 

prescnpuondataand me pharmaauucaldatatodetermuieif 10 system ^ fllustrates ^ flow of d ^ 

the patient prescript** data is within an acceptable medi- communication within the system and method of use of the 

cation administering duration range as defined by the phar- system 

maceutical data, and to transmit the determination to the rTr , - . . - , 

reporting unit IG ' 3 1S a s^ 0 ™* 10 of a preferred embodiment of the 

- A " , . ... . , . . , 15 computer software architecture utilized by the system and 

In another preferred embodiment of the invention, the the method of use of the system detailing me steps taken by 

CPU is further programmed to compare the patient data, the the physician and the reports generated by the system 

patient prescription data and the pharmaceutical data to CT ^ ia - i_ . r * , 

determine if the patient prescription data is within an accept- FIG ; 3A H £ schcmat ' c of a preferred embodiment of the 

able medication maintenance dosage or within an acceptable TiT f ^ arC f hltCCtur ' utmzcd ^ s y stera to 

medication acute dosage range as defined by the pharma- 20 ^ dfUg d ° Smg fof 0Ver dose > ™ dei dose > ^ 

ceutical data, and to transmit the determination to the "icrapy. 

reporting unit. FIG - 3A_ 1 is a schematic of a preferred embodiment of 

In still another preferred embodiment of the invention, the * c of ' computer software architecture utilized 

CPU is further programmed to generate from approved ^ T t0 dete ™™ * Prescribed drug regimen is 

patient prescription data a patient message, and wherein the 25 Wlthm the recommeilded aild ™* d ™g dosage ranges, 

system further comprises a message receiving unit opera- FIG - 3A ; 2 ^ a schematic of a preferred embodiment of 

lively connected to the CPU to receive the patient message the subr outine of the computer software architecture utilized 

from the CPU. In a more preferred embodiment, the mes- the system to determine if the prescribed drug regimen is 

sage receiving unit will comprise a modem operatively 3Q mc recommended drug duration range, 

connected to a transmission unit which can transmit the FIG. 3B is a schematic of a preferred embodiment of the 

patient message to a pager. Alternatively, there may be computer software architecture utilized by the system to 

embodiments wherein the CPU and the transmission unit are check for adverse drug interactions among the drugs 

directly connected and do not need a message receiving unit included in the patient medical regimen, 

(e.g. modem) to accomplish communications between the 35 FIG. 4 is a schematic of a preferred embodiment of the 

CPU and transmission unit. computer software architecture utilized by the server system 

In still another preferred embodiment of the invention, the to forward to the patient messages relating to the patient's 

CPU is further programmed to generate a prescription medical regimen, 
delivery message, and wherein the system further comprises 

a message receiving unit operatively connected to the CPU 40 PREFERRED EMBODIMENTS OF THE 

to receive the prescription delivery message from the CPU. INVENTION 

In a further preferred embodiment of the invention, the Although it is within the scope of this invention that each 

system comprises two or more linked computer systems. prescriber could be equipped with a computer system that 

One computer system is the server computer station and the would perform all of the functions discussed below, the 
other computer systems are prescriber computer systems. 45 preferred system includes a central server computer system 

The server computer station will serve as the repository of A to which will be operatively connected to one or more 

the data bases used by each of the prescriber computer prescriber computer systems B. In this preferred embodi- 

systems and will deliver that portion of the data bases ment the central processing units (CPUs) of each computer 

requested by one of the prescriber computer stations. Each system will be programmed to perform separate tasks. In the 
prescriber computer station shall then process the informa- 50 stand alone system, the CPU of the prescriber will be 

tion provided by the server computer station, as well as programmed to perform all of the separate tasks. It is also 

information which it may have stored in its own data base within the scope of this invention that the tasks to be 

storage unit, in accordance with instructions set forth in its performed could be achieved by either the server CPU or the 

operating program. The prescriber computer station will be prescriber CPU through well known and easy to perform 
further provided with one or more communication units, 55 programming changes. It is also within the scope of this 

such as a modem, for transmitting messages, including invention that the retention of the various types of data 

prescription orders, determined by the results of the pro- maintained by the system could be retained either in the 

ccssed information to the server computer station. The internal hard drives of the server computer system A or the 

server computer station upon receipt of these messages, and prescriber computer system B, or in external memory units 
in accordance with its operating program, will timely trans- 60 operatively attached to either, or through the use of other 

mit these messages to pre-detennined parties. known data storage media. 

BRIEF DESCRIPTION OF THE DRAWINGS The Computer Hardware Utilized in the Preferred 

The specification and the accompanying drawings show System 

and describe a preferred embodiment of this invention, but 65 It is seen from FIG. 1 that in the preferred embodiment of 

it is to be understood that this embodiment is not intended the invention, the system comprises a server computer 

to be exhaustive nor limiting of the invention, but on the station A, and a prescriber computer station B which are 
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programmed to provide drug dosage, administering telephone which incorporates a digital paging function. A 

duration, drag interaction and patient drug reaction checks pager could also include a miniature portable computer such 

from the data stored in the two stations. In a more preferred as "palm" computers which allow wireless communication 

embodiment, the system will also comprise a patient mes- with the Internet Therefore, a page be in the form of a 

sage receiving system C through which the patient can be 5 conventional E-mail message and a pager be any device 

timely reminded to take the medication contained in the capable of receiving the E-mail message. One such palm 

medical regimen. In another more preferred embodiment, computer is the PALM III™ manufactured by 3Com Cor- 

the system will also comprise a prescription distribution poration of Santa Clara, Calif. The preceding description of 

system D that enables quicker initial delivery and which pager embodiments is intended to be illustrative only and 

better ensures timely refills of prescriptions. In still another 10 those skilled in the art will recognize many other existing or 

more preferred embodiment, the system may also comprise future addressable communication devices could come 

an invoice payment system E that expedites payment, and within the definition of pager. 

reduces payment processing costs. With the equipment con- m a preferred embodiment, the prescription distribution 

tained in each system, each of the communications graph- system D includes a modem 17 and a CPU 18 for receiving 

cally depicted in FIG. 2, and discussed below, is made 15 the mformation and transcribing this information in a format 

possible. ' mat enables one to prepare the medication prescribed by the 

In the most preferred embodiment, the server computer In a ?° re J^V* i embodiment > Prescription 

stauonAcomprisesacentralprocessingunitCCP^ljadata ^bution system D will also comprise a reporting unit, 

storage unit, such as a disc L/or hard drive 2, for toring ^± " $*"J* *°* t monitor 20, which permits 

«aHA«t a**» ™™ #• a i u i j r viewing of the billing statement and subsequent printing of 
IT,1 ^P^r P P harmacelltical ? ata » . hard copy of the biUing statement that isto be transmitted 

and the CPU soperating programs; a data input unit, such as to the payor of the meditation delivered to the patient. The 

a keyboard 3, for inputting data or operating instructions into payor may be the patient, a healthcare payor, or government 

CPU 1; one or more communication units, such as modems agency. 

4 and 5, for transmitting data or messages to the prescriber In a preferred embo di m en1, the ^voice t tem E 
computer station B or the patient m^age receiving system « ^ inchlde a computer te including modem 21 opera- 

C; and a printer 6 for preparing hard I copies of invoices or tivcl lo me prescription distribution system D to 

reports generated by the server CPU 1 or the prescriber receive a bim statement for ^ medication prescribed) a 

computer station B. Each of the elements making up the CPU 22 to process the information contained in the billing 

server computer station A are operatively connected to one statement, as well as a CRT monitor 23 and printer 24 to 

another by well known means, such as hard winng, tele- 30 view an(J rint checks> m wdl as ofl]er Morination . M 

phone hr.es, microwave transmission means, and similar reflecled in p IGS j and 2 , his information can u , uize lhe 

devices, to permit the functions which each element nor- servet s tem A „ , ^ for ^ billi 

mally performs. Additionally, where this specification dis- statement . If serV er system A is provided with a data base 

cusses communication through modems, the manner of C0Dtaining the payor identification and drug cost charged by 

commumcahon is not necessarily limited to moderns. Where 35 me prescription delivery D> As . n se * er systen f A can 

feasible certain modem communications described herein directly enerale ^ , he bmin stiU . menl to me 

could be accomplished through network connections or payment system E 

various wireless communications. . ..' . .. ^ , , 

_ _ . Alternatively, the prescription delivery system D and the 

ine presenter computer station a comprises a central payor (em E be , inked . m 

uters to 

processing unit (CPU) 7; a data storage unit, such as a CD 40 me ba]iog statement ^ make ayme J^tty 

and/or hard drive 8 for storing patient and patient medical to & c prescription delivery system D . 

Su D ni , suchf, S 9 °P eratin 8 tl ? ro ^ 3 data It is within the scope of this invention that for each of the 

Zt ^^il^ui' T 8 1 01 T" computer elementsused in the server computer station A, the 

™™,n7^ rl, n « • ? ,° r V f° P rcscribel <=° m P ute ' stati ° n B> «* patient message uni C, 

monitor 10 a pnnter 11; and a communication unit, such as 45 fk„ a- * u *,* * t>» .1. 

A „n r , 1 4 > , . . ' A . 3 the prescnption distnbution system D, or the payment 

modem 12, for transmitting data to and receiving data from , „ c a - u- L / ^ n. 

. * * * a c *i system E, devices which perform the same function, or 

the server computer station A. Similar to server computer V u t F , iL , t . , " > " \ 

etitinn a n f *u a 1 * .• *u u ^" lCi which perform one or more of the functions described, could 

station A, each of the elements making up the prescriber Ua ^ui^^A *u pa i * , 

* o 1 1 be substituted for the preferred computer element or ele- 

computer station B are also operatively connected to one t * , - ... , , , 

another by well known means tTpermit [be functions which 50 Z^^J^C^toTT ^ m 

each element normally performs subsUtuted for the keyboards 3 or 9. Another example would 

r r j . f • , . include the substitution of a speaker system for the monitors 

In a preferred embodiment, the patient message unit C 10 , 2 0, or 23. A still further example would include the use 

comprises a message receiving and sending means 13 and a of separate dalabase st mits ^ M , tems for 

pager 14 and more preferably a two-way pager. Means 13 the hard drives 2 or 8. The particular computer hardware that 

wiU mclude a modem 15 and a pager transmitting unit 16. 55 ^ ^ ^ nol critical It k important) however> ^ there be 

In a more preferred embodiment pager 14 « . two-way a ter element t to rform me desked fMction 

pager to permrt the patient to confirm receipt of the message, ^ term .< conipu , er » h intcnded to mclude aU existing and 

as well as respond to any queries contained in the message. fetBre computing dev i ccs . By way of example, present 

Such inquiries may mclude questions related to the health of complUe rs include palm top computers or personal digital 

toe patient. The term pager^ as used throughout thisspeci- 60 assislants (PDA . s) . It shou f d unde 4, od , hat 

fication « intended to include within its definition any munications be t ween various coinponente of the system 

addressable commumcaUon device which is capable of need not be ^ or mro h dedi J, ed ljne ^ ^ d b( , 

receiving a message. Such an addressable communication v j a (ne r n t ern et 
device could be capable of providing one-way or two-way 

communication. Preferably, the addressable communication 65 Th e Communications Amongst Users of the System 

device will be portable. Thus, a pager could include a cellar FIG. 2 illustrates an overview of a preferred use of the 

or digital wireless telephone and in particular a wireless server computer station A to obtain a preferred flow of data, 
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reports, and messages amongst the physician, the prescrip- system A, respectively, to perform each of the steps involved 

tion distribution service organization, the patient, and the in developing and monitoring a prescribed drug regimen, 

prescription payor. The various channels of information flow FIGS. 3A and 3B are preferred software subroutines used in 

are described below as indicated by the information flow the prescriber computer system B to check whether the 

numbers in FIG, 2. 5 prescribed drug is within the recommended dosage range 

1. The prescriber utilizing the prescriber computer station and whether the prescribed drug creates any objectionable 
B enters information about the patient that is then transmit- interaction with other drugs which the patient is taking, 
ted to the server computer station A. If the patient is respectively. FIG. 3A-1 is a more preferred software sub- 
currently being prescribed by another prescriber in the routine within the dosage range check routine to determine 
system, or has been prescribed in the past by a prescriber in 1Q if the prescribed drug regimen is within the recommended 
the system, the patient's billing, medical, and prescription daily dosage range and within the recommended unit dos- 
history will already exist within the server data base Unit 2. age. FIG. 3A-2 is a more preferred software subroutine to 
This information will be communicated to the prescriber determine if in the standard medication mode, the total 
computer station B. dosage is within the recommended duration range. 

2. The patient is assigned a pager 14. If the patient already 1 - Inputting the pharmaceutical data As one of the initial 
has pager 14 the assignment is not necessary. 35 steps in preparing the system for use, pharmaceutical data 

3. Prescription information for the patient is entered into wil1 be inputted and stored in the server data storage unit 2. 
the system by the prescriber. This information includes, but f or eacn dni g m *h e pharmaceutical data base, this data will 
is not limited to, drug name, units and strength, prescription include the prescription identification code (which will be 
signature, refills, dosing mode, and a date and time that the fmmd in the GPI or NDC identification codes), the GPI, the 
first dose is to be administered. Pharmaceutical information 20 mC ? nd ^ ^ class of chemical components of the 
related to the drugs being prescribed is transmitted from the P res <fbed drug the recommended unit dosage, the recom- 
servercomputerstationAtotheprescribercomputersystem me " ded standard daily dosage range the recommended 
B. Ihcrc the pharmaceutical information is compared to the ^te dosage range including the unit daily, and prescribing 

«j# j *• * • *• j * * • T *t. duration acute ranges, the recommended maintenance unit, 

patient data and patient prescription data to ascertain if the ^ md J e and ^ recommeDde J 

drug regimen is within recommended ranges and to deter- ^te, or routes, m which tL dmg is to be administered. This 

mine if any drug interaction problems exist. These include a data is provided by the various pharmaceutical companies to 

series of tests performed on the prescription to see if it may me tj s . fda which accumulates and distributes the infor- 

have adverse effects. These tests include, but are not limited mation> While this specification generally discusses pre- 

to underdosing, overdosing, length of therapy, drug-drug scription drugs, it should be understood that the scope of the 

interactions, drug-food interactions, drug-alcohol present inven tion includes both nonprescription "over-the- 

interactions, and pnor adverse reactions. Any of these cir- counter" medications and nontraditional medications. 

cumstances will be reported to the person, such as the Examp i es of nonprescription medications include aspirin, 

treating physician, entering the prescription information, Ty lenol ^ co mmon co ld remedies, etc. Examples of nontra- 

where an appropnate action can be taken. ^ ditional judications could include herbal substances, 

4. Once the drug regimen has been finalized, the prescrip- vitamins, or various holistic medical preparations. 

tion data is transferred to the server for validation, 2. Inputting the patient and patient prescription data The 

certification, and distribution. prescriber will in most cases, but not necessarily in all cases, 

5. Messages are scheduled for distribution to the patient be the patient's treating physician who desires to prescribe 
via the patient message receiving system C. This schedule 4Q a particular medication to the patient to assist in the treat- 
can easily be changed by the prescriber through the system. me nt of some medical illness. The prescriber computer 

6. Prescriptions can be distributed to a prescription dis- station 7 is constructed to permit the prescriber to input into 
tribution company, such as a pharmacy, or drug wholesale the system that patient data and patient prescription data 
company, and in turn the distribution company can, via the necessary for the prescriber to ascertain that the dosage of 
server, invoice the payor (see 11 below). 45 the prescribed medication is within the recommended stan- 

7. Patient reporting may be provided, including but not dard unit dosage, daily dosage or duration ranges, acute unit 
limited to, general information, prescription history, and and daily dosage ranges, as well as the acute duration range; 
prescription calendar. This reporting would be made to the maintenance unit and daily dosage ranges, as well as the 
prescriber via the server, or could be made directly to the maintenance duration range, or if there is likely to be a 
prescriber. 50 drug-drug interaction, a drug-food interaction, a drug- 

8. Responses to the messages are received from the alcohol interaction; or if there has been a prior adverse 
patient and recorded for reporting to the prescriber. reaction by the patient to the particular drug or class of drugs 

9. Compliance information is reported to the prescriber. being prescribed. 

This type of reporting is available only if the patient message The patient prescription data will include the patient's 

receiving system C is capable of providing an answer back 55 identification code (e.g., social security number), the pre- 

capability, such as may be provided by a two-way pager. scrip tion GPI or NDC, the prescribed unit dosage, the 

10. Changes to the prescription including drug, time and prescribed daily dosage, the number of refills, the schedule 
date of treatments, etc. are communicated to the prescriber. °f taking the prescribed drug, including time of first admin- 
All changes are initiated by the prescriber, who can make the istration and frequency of administration, and the adminis- 
changes via the steps described above. 60 tering mode (i.e., standard, acute or maintenance mode). The 

11. Billing and other communications can be made with P atient P resc rip*ion data will also include similar informa- 
the prescription payor. ^ion ^ or an y otner drug which the patient is currently taking. 

The patient prescription data can also include for each drug 

The Method of Utilizing the System for Medical ^ mc mcdical rcg i m en the prescribed name, the prescrib- 

Regimen Integrity 65 er > s p racucc name, address, and telephone number. 

FIGS. 3 and 4 illustrate a preferred scheme using the In a more preferred embodiment of the invention, it will 

prescriber computer system B and the server computer also permit the inputting of patient data that will include the 
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information necessary to expedite the delivery of the pre- server storage unit 2 and the prescriber storage unit 8 to 
scribed medication to the patient, to expedite the payment determine if a pager had been previously assigned to the 
process for the prescribed medication, to generate patient patient. If no pager has been previously assigned to the 
messages to prompt the timely taking of the prescribed patient, then in step 201 a pager is assigned by inputting the 
medication; and to continue to monitor the taking of the 5 pager identification code into the patient data. This infor- 
prescribed medication. mation is transmitted to the server computer system A which 

This patient data would include the patient's name, social will in step 202 transmit a test message in accordance with 
security number, and address. It can also include the iden- the procedure described in FIG. 4 and discussed below, 
tifi cation code of the pager assigned to the patient, as well 4. Entering the patient prescription data. Upon verification 

as the name, address, telephone number, facsimile number, 10 that a pager has been assigned to the patient, the prescriber 
or identification number of the prescription delivery service then inputs in step 300 through keyboard 9 that portion of 
D to be used to prepare and deliver the prescription. It can the patient prescription data identified above that is neces- 
also include similar information regarding the entity, if other sary to verify that the prescription complies with a recom- 
than the patient^ who will pay part or all of the cost of the mended dosage range, a recommended administering dura- 
prescnption. The patient data may also include medical tion range, is free of adverse drug-drug reactions, dru^-food 
history information relating to the patient, such as prior 15 a„,„ *■ Ji • J . 

nA„~„~ * - c j , \ . . j F , reactions, drug-alcohol reactions, and known prior patient 

adverse reactions to specified drugs. It may also include such adverse ^ factions 
other information as patient height and weight, or any other r ... . . . 

general health information which the prescriber may believe . From ™™ patient P I&scn P^ da *a and the patient data, 
beneficial in establishing a medical regimen for the patient. toc P rcscn J> cr cpu 7 is in step 400 programmed to generate 
Turning now to FIG. 3, in step 100, the prescriber logs 20 a dm & regimen that is then transmitted through modems 12 
into the software program and enters the patient's identifi- 4 to lI ? e servcr CPU 1 for retenlion in server data 

cation code. The preferred identification code will be the storage unit 2. 

patient's social security number. The software will automati- * n a preferred embodiment, the prescriber will indicate if 
cally connect the prescriber CPU 7 to the server CPU 1 information identifying the drug being prescribed is to be 
through the use of modem 12 and modem 4. The server CPU 25 made available to other prescribers. This embodiment per- 
1 will search the patient data contained in the server data mits the prescriber to maintain certain information confi- 
storage unit 2 to determine if previous patient data or patient dential and be disseminated on a need-to-know basis. This is 
prescription data had been entered regarding the particular achieved by designating at step 500 the drug description as 
patient in question. If so, ibis information is then transmitted confidential. Although a drug has been designated as 
to the prescriber CPU 7. If not, then in step 101 the 30 confidential, the system is preferably designed to still per- 
prescriber will input through keyboard 9 the necessary form the dosage range check, the drug interaction checks 
patient and patient prescription data. The prescriber CPU 7 and the prior patient adverse drug reactions check. Thus^ 
is further programmed to display the patient data on monitor another prescriber will know if the unidentified drug causes 
10 or, at preserver's option, to print a hard copy of the any problem with a drug which the prescriber may wish to 
patient data by use of printer 11. There is no preferred 35 administer. In this circumstance, a message providing the 
software to accomplish the above tasks. Any of the many prescriber's name and telephone number will be entered into 
commercially available data base and communication soft- the patient data. When the patient data is subsequently 
ware programs can be used. While FIG. 3 describes the recalled, another prescriber will thus have the ability to 
prescriber CPU 7 as having a program to carry out the contact the originating prescriber and determine the identity 
functions described in FIG. 3, it will be clear to those skilled 40 0 f the prescription 

in the art that such functionality could be achieved without [d another prcferrcd embodiment , me preS criber can indi- 
the program being in the memory of the computer housing cate if me drug being prescribed fc an experimental drug, 
prescriber CPU 7. Rather, one alternative would be to have ^ is also achieved fa step 500 by designating the d * 
tne functionality or the prescriber program incorporated into experimental. However, in this event there is no further drue 
a website In this manner, the prescriber would not need 45 dosage check or d interaction check, as there will not be 
specialized software, but only need sufficient conventional sldEdgsai mforrnation m ^ data bases to makc those 
hardware and software so as to be web capable. determinations. 

3 Assignment of Pager As indicated above, one of the 5 . p reS cribed Dosage Check Procedure. Upon the trans- 
preferred embodiments of this invention is a reminder miUal of the drug regimen to m 8MVCr data stQ ^ 2 
system which provides prior notification to the patient that 50 the prescriber CPU 7 is programmed in step 600 to request 
certain of his Prescribed medications should be adminis- tnat me XTVeT CPU 1 retrieve from the SHVer data stQ 4 
tend One of the problems with prior art systems is that ^ 2 the pharmaceutical data relating to each of the 
patients are mobile. As a result many of the reminder prescriptions contained in the schedule, as well as to each of 
messages are not timely received by the patient. Therefore, me other prescriptions which the patient is currently taking, 
the preferred mode of communicating with the patient is by 55 with this information, and as further described in FIG. 3A, 
pager 14. tnc prescr i bcr qjfj 7 { s programmed to check each prescrip- 

In a more preferred embodiment, the pager 14 will be a tion to determine if it is within the recommended unit dosage 
two-way pager which permits the patient to indicate receipt range or the recommended daily dosage range, as well as 
of the message. This system also permits the message to within the recommended medicating duration range for the 
include not only a reminder to take the prescribed 6 0 prescribing mode; i.e., standard, acute, or maintenance. In a 
medication, but also to query the patient on other health preferred embodiment, the program is constructed to default 
matters, and to receive from the patient an updated status as to a standard dosage mode. However, if the prescriber had 
to the health of the patient, the effectiveness of the pre- indicated that the drug regimen has been set for a raaintc- 
scribed medical regimen, or any health problems that may nance or acute dosage, then as detailed below in FIG. 3A, 
have arisen as a result of the prescribed medical regimen. 65 each such prescription is checked to determine if it is within 

To effect this preferred mode, in step 200 the software the recommended maintenance dosage ranges or the recom- 
program is structured to search the patient data located in the mended acute dosage range, whichever may be indicated. 
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If the prescription is not within the recommended ranges, 
then the prescriber CPU 7 is programmed to display this 
information on the prescriber monitor 10 where the pre- 
scriber is directed to amend the prescription to be within the 
recommended ranges. 

(a) Dosage and Duration Range Check 

FIGS. 3A, 3A-1, and 3A-2 provide a preferred software 
routine for the method of conducting a comparison of the 
patient data and the patient prescription data to the associ- 
ated pharmaceutical data to determine if there arc any 
deviations from recommended dosage or duration ranges. 

In addition, the prescriber CPU 7 has been programmed 
to transmit its determinations to prescriber monitor 10 and 
printer 11. Also, along with the determinations, suggested 
actions may be provided to the prescriber. Although the 
language used, as well as the content of the determinations 
and suggested actions may vary within the scope of the 
invention, the following would be exemplary of the mes- 
sages provided to the prescriber or physician: 
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the software program could be easily modified to accom- 
modate such changes. 

Next, in step 602, the prescriber central processing unit 7 
is programmed to determine if the patient age is 65 or 

5 greater. Then the GPI or NDC is read at step 603. If the GPI 
or NDC is not stored in the server data storage unit 2, 
prescriber central processing unit 7 will perform step 604 to 
transmit to prescriber report unit 10 a message that geriatric 
dose range checking is not available. The message may also 

10 provide guidance to the prescriber, such as comparison to 
normal adult dosing may or may not be appropriate 
(Message Number 2). The prescriber CPU 7 is then further 
programmed to begin at step 612, described below, to check 
to determine if there is a prescription identification number 

15 included within the adult dosage category. If the GPI or 
NDC is stored in the server data storage unit 2, then the 
prescribed dosage and the recommended adult dosage range 
are compared in step 60S to determine if the prescribed 
dosage is within the recommended adult dosage range. 

(i) Dosage Range Check. Step 605 is set forth in more 
detail in FIG. 3A-1. In the first step 605Athe prescriber CPU 



MESSAGE NUMBER MESSAGE DESCRIPTION 



1 Adult Dose Checking is not Available. 

2 Geriatric Dose range checking is not available. Comparison to 
normal adult dosing may or may not be appropriate. 

3 Pediatric Dose Range Checking is not available. Consult a pediatric 
dosing reference is recommended. 

4 Infant Dose Checking is not available. Consult a pediatric dosing 
reference is recommended. 

5 This dose falls below the recommended daily dose for this drug and 
is potentially subtherapeutic. 

6 This dose falls above the recommended daily dose for this drug. 
Please verify this daily dose. 

7 This dose falls above the recommended maximum individual dose 
for this drug. Please verify the dosage regimen. 

8 No further information available. 

9 This dose falls below the recommended maintenance dosage range 
for this drug and is potentially subtherapeutic. 

10 This dose falls above the recommended maintenance dosage range 
for this drug. Please verify this daily dose. 

11 This dose falls below the recommended acute dosage range for this 
drug and is potentially subtherapeutic. 

12 This dose falls above the recommended acute dosage range for this 
drug. Please verify this daily dose. 

13 The duration of therapy falls below the recommended duration of 
therapy range for acute dosing and is potentially ineffective. 

14 The duration of therapy exceeds the recommended duration of 
therapy range for acute dosing of this drug. Please verify the 
prescribed length of acute therapy. 

15 Minimum Duration of Therapy is not available. 

16 Maximum Duration of Therapy is not available. 

17 The duration of therapy falls below the recommended duration of 
therapy range and is potentially ineffective. 

18 The duration of therapy exceeds the recommended duration of 
therapy range for this drug. Please verify the prescribed length of 
therapy for this drug. 



When these messages are preferably transmitted is set forth 
below. 

The first step 601 is to calculate the age of the patient from 
the information in the patient data. If this information is not 
in existing patient data, then the prescriber will input in the 
necessary information to calculate the age of the patient. 

Recommended dosage ranges may vary depending on the 
age of the patient. Currently, dosage ranges have been 
defined for infants (ages of 0-1), adolescents (ages of 1-14), 
adults (ages 14-65) and geriatrics (ages >65). This age 
division is used by the system to provide dosage range 
checks. Obviously, if these current divisions change, then 
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7 is programmed to calculate a Dose Unit (daily dosage). 
This is obtained by dividing the total drug quantity by the 
prescribed duration. In step 605B the prescriber CPU 7 is 
programmed to calculate an IndividualDose (unit dosage). 

60 This is obtained by dividing the DoseUnit by the frequency 
a patient is to take the medication. Next, in step 605C a 
comparison is made by the prescriber CPU 7 between the 
prescribed daily dosage and the recommended minimum 
daily dosage. If the prescribed daily dosage is less than the 

65 minimum recommended daily dosage, prescriber CPU 7 is 
programmed in step 605D to generate a message for trans- 
mission to the prescriber monitor 10 and then proceed to step 
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605E. The message would indicate that the prescribed daily sponding to the GPI is located in the server data storage unit 

dosage is less than any dosage in the recommended total 2, in step 613, the prescriber CPU 7 is programmed to begin 

daily dosage range and that the prescribed dosage is poten- Dose Range Check step 60S. In a preferred embodiment the 
tially subtherapeutic (see Message Number 5). However, if DNC will contain a corresponding GPI designation for each 

the prescribed daily dosage is greater than the recommended 5 drug in the DNC. Thus, if the prescriber inputs DNC 

minimum daily dosage, the prescriber CPU 7 is programmed designations into the prescriber CPU 7, the software is 

in step 605E to compare the prescribed daily dosage to the designed to located the corresponding GPI designation and 

recommended maximum daily dosage. If the prescribed then to utilize the GPI designation to obtain the necessary 

daily dosage is greater than the recommended maximum data to perform the checks. 

daily dosage, then the prescriber CPU 7 is programmed in 10 In step 615, prescriber CPU 7 is programmed to determine 
step 605F to generate a message for transmission to the if the patient prescription data indicates that the prescription 
prescriber monitor 10 and then proceed to step 605G. The dosage is a maintenance dosage. If so, then prescriber CPU 
message would indicate that the prescribed dosage falls 7 is programmed to determine if the prescription dosage is 
above the recommended daily dose for the drug, and within associated recommended maintenance dosage 
requests the prescriber to verify the prescribed daily dose 15 ranges. In step 616, it is determined if the prescription 
(See Message Number 6). If the prescribed daily dosage is dosage is greater than the maximum maintenance dosage in 
less than the maximum daily recommended dosage, then the the recommended maintenance dosage range. If not, then, in 
prescriber CPU 7 in step 605G compares the prescribed unit step 617, it is determined if the prescription dosage is less 
dosage to the recommended maximum unit dosage. If the than the minimum maintenance dosage in the recommended 
prescribed individual dosage is greater than the recom- 20 maintenance dosage range. If it is, then, in step 618, the 
mended maximum unit dosage, prescriber CPU 7 is pro- prescriber CPU 7 is programmed to generate a message that 
grammed in step 605H to generate a message for traosmis- the dosage falls below the recommended maintenance dos- 
sion to prescriber monitor 10 that the prescribed dosage falls age range for this drug and is potentially subtherapeutic, 
above the recommended unit dosage for the drug, and (See Message Number 9) If in step 617 the prescribed 
requests the prescriber to verify the prescribed dosage 25 dosage is greater than the recommended minimum mainte- 
regimen (See Message Number 7) and to proceed to the nance dosage, then the prescriber CPU 7 is programmed to 
maintenance mode range check at step 615. If the prescribed conclude the dosage check subroutine and to proceed with 
unit dosage is below the recommended unit dosage, then the drug interaction check subroutine, 
prescriber CPU 7 is programmed as described below to If in step 616 the prescribed dosage is greater than the 
determine if the prescribed dosage is within the mode ranges 30 recommended maximum maintenance dosage, then in step 
being prescribed. 619 the prescriber CPU 7 is programmed to search to 
Returning now to FIG. 3A, if the age of the patient is less determine if an acute dosage record exists. If no record can 
than 65, but determined in step 606 to be less than 14 years, be found, then in step 620 the prescriber CPU 7 is pro- 
then, in step 607, it is determined if the age of the patient is grammed to generate and transmit to prescriber monitor 10 
greater than one year. If not, then, in step 608, prescriber 35 a message that the prescribed dosage falls above the rec- 
CPU 7 is programmed to generate a message that infant dose ommended maintenance dosage range for the drug, and 
checking is not available. It may also recommend that the requests the prescriber to verify the daily prescribed dosage, 
prescriber consult a pediatric dosing reference (See Message (See Message Number 10) Upon transmission of the 
Number 4). Once the message has been transmitted, the message, the prescriber CPU 7 is programmed to terminate 
prescriber CPU 7 is programmed to terminate the dosage 40 the dosage check subroutine and to proceed with the drug 
check subroutine and proceed to the drug interaction check interaction check subroutine. 

subroutine. If the age of the patient is determined to be If the prescription data indicates that the dosage pre- 
between 14 years and one year, then, in step 609, the GPI or scribed is an acute dosage, then in step 621, the prescribed 
NDC is read from the prescription data. If, in step 610, no dosage is checked to determine if it is within the recom- 
matching GPI or NDC can be located in server data storage 45 mended acute dosage range associated with that prescrip- 
unit 2, then prescriber CPU 7 is programmed in step 611 to tion. If the prescribed dosage exceeded the maximum acute 
generate a message that pediatric dose range checking is not dosage range, then, in step 622, the prescriber CPU 7 is 
available. The message may recommend that the prescriber programmed to generate a message that the dose falls above 
consult a pediatric dosing reference (See Message Number the recommended maximum acute dosage for this drug. The 
3). Once the message has been transmitted, the prescriber 50 message can include suggestions to the prescriber such as 
CPU 7 is programmed to terminate the dosage check sub- requesting the prescriber to verify the daily dosage. (See 
routine and to proceed to the drug interaction check sub- Message Number 12) Upon transmission of the message, the 
routine. However, if a GPI or KDC is located in step 610, prescriber CPU 7 is programmed to begin the drug interac- 
then prescriber CPU 7 is programmed to perform step 605 tion check subroutine. If the prescribed dosage is not greater 
previously described. 55 than the maximum acute dosage in the recommended acute 
If, in step 606, the age of the patient is determined to be dosage range, then, in step 623, it is determined if the 
between 15 years and 65, then, in step 612, the GPI in the prescribed dosage is less than the minimum acute dosage in 
prescription data is read by the prescriber CPU 7 and the recommended acute dosage range. If it is, then, in step 
compared in step 613 to the GPI's stored in server data 624, the prescriber CPU 7 is programmed to generate a 
storage unit 2 to determine if pharmaceutical data is stored 60 message that the prescription dosage falls below the recom- 
in the server data storage unit 2 corresponding to the GPI. If mended acute dosage range for this medication and is 
not, then, in step 614, prescriber CPU 7 is programmed to potentially subtherapeutic. (See Message Number 11) Upon 
generate a message that adult dosage checking is not avail- transmission of the message, the prescriber CPU 7 is pro- 
able (See Message Number 1). After the message has been grammed to begin the drug interaction check subroutine, 
transmitted, prescriber CPU 7 is programmed to end the 65 However, if the prescription dosage is not less than the 
dosage range check and to begin the drug interaction check minimum acute dosage in the recommended acute dosage 
subroutine at step 700. If the pharmaceutical data corre- range, then, in step 625 the prescriber CPU 7 is programmed 
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to calculate the prescribing duration for the drug being for the drug being checked. If so, a message to this effect 

checked. The prescribing duration is determined by dividing (See Message Number 18) is generated and transmitted to 

the total quantity prescribed by the daily quantity prescribed. Monitor 10. 

Then with the calculated prescribing duration, prescriber 6. Drug Interaction Checking Procedure. Prescriber CPU 

CPU 7 is programmed to determine in step 626 if the 5 7 is next programmed in step 700, as referenced in FIG. 3 

prescribing duration period is greater than the maximum and 3B, to retrieve from the previously transmitted pharma- 

acute duration period in the recommended acute duration ceutical data now stored in the server data storage unit 2 the 

period range. If the prescribing duration period is greater, information necessary to determine if any of the drugs 

then, in step 627, the prescriber CPU 7 is programmed to included within the medical regimen will cause an unac- 

generate a message that the duration of therapy exceeds the 10 ceptable reaction with any other drug included within the 

recommended duration of therapy range for acute dosing of medical regimen. The preferred subroutine is illustrated in 

this drug. It may also suggest that the prescriber verify the FIG. 3B. 

prescribed length of acute therapy. (See Message Number In step 701, the prescriber CPU 7 is programmed to create 

14) If the prescription duration period is less than the an empty interaction list. Next, in step 702, the prescriber 

maximum duration period in the recommended duration is CPU 7 is programmed to compare the GPI of a prescribed 

period range, then, in step 628, it is determined if the drug with the NDC stored in the server data storage unit 2 

prescription duration period is less than the minimum dura- in order to collate the GPI with the corresponding NDC to 

tion period in the recommended duration period range. If locate the KDC. If in step 703, the corresponding KDC is 

not, then the prescriber CPU 7 is programmed to terminate located, then in step 704 the KDC is retained by the 

the drug dosage check and to proceed to the drug interaction 20 prescriber CPU 7. The prescriber CPU 7 is programmed in 

check subroutine. However, if the prescription duration step 705 to include the finding in a final report. If the KDC 

period is less than the minimum recommended duration in step 703 was not found, then the prescriber CPU 7 is 

period, then, in step 629, prescriber CPU 7 is programmed programmed to retain that finding. In the next step 707, 

to generate a message that the duration of therapy falls prescriber CPU 7 searches the pharmaceutical data to look 

below the recommended duration of therapy range for acute 25 for the drug formulation record (containing the compound 

dosing and is potentially ineffective. (See Message Number classes which the drug contains) for each drug in the medical 

13) Upon transmission of the message, the prescriber CPU regimen. If at step 708 the record is found, then prescriber 

7 is programmed to begin the drug interaction subroutine. CPU 7 is programmed at step 709 to create a list of classes 

If the prescription is not a maintenance mode dosage or if that each drug in the medical regimen would be classified, 

no maintenance record can be located in step 615, then 30 and at step 710 to retain the finding. If at step 708 no drug 

prescriber CPU 7 is programmed to determine in step 630 formulation record could be found, then prescriber CPU 7 is 

whether an acute mode record exists. If an acute mode programmed to retain at step 711 this finding. The prescriber 

record exists, then prescriber CPU 7 is programmed to begin CPU 7 is programmed to compare the classes of each drug 

step 621 as described above. If no acute mode record exists, in the medical regimen to determine at step 712 if there 

then prescriber CPU 7 is programmed to begin in step 631 35 would be any anticipated unacceptable drug interactions 

the drug prescribing duration check subroutine. because of the compound classes in which a drug may be 

(ii) Prescribing Duration Check Referring now to FIG. included. Any unacceptable drug interactions located are 

3A-2, prescriber CPU 7 is programmed to calculate the accumulated in a list at step 713. If there are unacceptable 

prescribing duration for each new drug to be prescribed in a drug interactions included in the list, then the prescriber 

medical regimen. This step 631 A is substantially the same as 40 CPU 7 is programmed to generate and then instruct pre- 

step 625. Prescriber CPU 7 is then programmed to search in scriber printer 11 in step 714 to print the findings of the drug 

step 631B the pharmaceutical data to determine if there is a interaction test or display on monitor 10 these findings. The 

recommended minimum prescribing duration period for the prescriber may then modify the drugs being prescribed to 

drug being checked. If none is found, then prescriber CPU eliminate the unacceptable drug interactions. If there are no 

7 is programmed to generate and transmit to monitor 10 in 45 unacceptable drug interactions, the prescriber CPU 7 is 

step 631 C a message, and then to proceed to step 631 D. The programmed to end the drug interaction check subroutine 

message would indicate that there is no recommended and to proceed to step 800 to check for prior patient 

minimum prescribing duration (See Message Number 15). reactions to any drug being prescribed in the medical 

Prescriber CPU 7 is programmed to then search the regimen, 

pharmaceutical data to detenninc in step 63 ID if there is a 50 If there are unacceptable reactions between drugs 

recommended maximum prescribing duration. If none is included within the medical regimen, the prescriber CPU 7 

found, the prescriber CPU 7 is programmed to generate and is programmed to display this information on the prescriber 

transmit to monitor 10 in step 631E a message, and then monitor 10. The prescriber then modifies one or more of the 

proceed to step 63 IF. The message would indicate that there drugs to eliminate the unacceptable reaction. The new 

is not a recommended maximum prescribing duration (See 55 prescriptions are then checked for compliance with both the 

Message Number 16). dosage and duration ranges, as well as for unacceptable drug 

If a recommended minimum prescribing duration was interactions. This procedure is repeated until the prescribed 

found in step 631F, then prescriber CPU 7 is programmed to medical regimen meets the recommended standards, 

determine in step 631F if the calculated prescribing duration 7. Prior Drug Reaction Checking Procedure. Once the 

is less than the recommended minimum. If so, then pre- 60 prescribed medical regimen is within the recommended 

scriber CPU 7 is programmed to generate and transmit to dosage and duration ranges and there are no unacceptable 

monitor 10- in step 631 G a message to this effect (See drag interactions, the prescriber CPU 7 is programmed in 

Message Number 17). The prescriber CPU 7 is also pro- step 800 to search the patient data to determine if the patient 

grammed after sending the message to proceed to step 631H. has ever reported any adverse reaction to any of the drugs, 

Similarly, in steps 631H and 6311, prescriber CPU 7 is 65 or classes of drugs, in the prescribed medical regimen, 

programmed to determine if the calculated prescribing dura- If so, the prescriber CPU 7 is programmed to display this 

tion is greater than the recommended prescribing duration information on the prescriber monitor 10. The prescriber 
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then modifies the prescribed medical regimen to eliminate These messages are sorted by delivery time. In the event a 
the unacceptable known reaction. The modified regimen is patient has more than one message; the server CPU 1 is 
then again checked for dosage, administering duration, drug programmed in step 1104 to combine all of these messages 
interaction, and prior known drug reactions. The procedure into a single message for transmission to the patient 
is repeated until the prescribed medical regimen meets all of 5 In step 1105, the number of messages is counted. If the 
the recommended dosage and duration range requirements, number of messages is greater than one, the server CPU 1 is 
and there is no unacceptable drug interaction and drug programmed in step 1106 to transmit through modem 5 the 
reactions. first message to the appropriate patient message receiving 

8. Report Generation Procedure. Once the medical regi- unit 13. step 1106 is repeated until all of the messages 
men has been set, the prescriber CPU 7 is programmed in 10 identified in step 1105 have been transmitted. This process 
step 900 to direct prescriber printer 11 to print for the patient, is continued until there are no remaining messages to be 
the prescription calendar and prescribed medical regimen for transmitted. The server CPU 1 is then programmed to again 
the patient to follow. The prescriber CPU 7 is further determine if a halt command has been received. The proce- 
programmed in step 1000 to transmit the final prescribed dure is then continued as before. 

medical regimen to the server CPU 1 for storage into the 15 The patient message receiving unit 13 upon receiving a 
server data storage unit 2. message is activated to call the patient's pager and deliver 
In a preferred embodiment, the prescriber will be able to the message. If the pager 14 is a two-way pager, the patient 
send to the patient more than prescription messages, such as win have been instructed to acknowledge receipt of the 
appointment reminders or refill reminders. In addition these message. If the message is more than notification to take 
messages could include instructions on how to take the 20 medication, the patient can also respond to any queries that 
medication, how to conduct various medical procedures may be i nc i u ded in the message. In this event, the server 
(e.g., how to clean, a wound, etc.), or combinations of both. CPU 1 is programmed to search at step 1108 for these reply 
In this embodiment aider step 900, the prescriber CPU 7 messages when the message count if greater than one. The 
asks the computer operator whether there are any non- collected messages are then transmitted at step 1109 to be 
prescription messages. If not, then the prescriber CPU 7 is 25 processed by the server. There are of course many alteraa- 
programmed to proceed to step 1000 described above. If tive procedures for routing the patient's response to the 
there are non -prescription messages, then the prescriber prescriber. For example, patient message receiving unit 13 
CPU 7 is programmed to receive in step 901 the message may bc fa^y connected to prescriber modem 12. In 
inputted by prescriber keyboard 9. Once the message has anot hcr alternative route, modem 5 can be directly con- 
been inputted, the prescriber CPU 7 is programmed to 30 nected t0 prescriber modem 12. 
produce in step 902 a schedule of non-prescription mes- 
sages. After the schedule has been produced, the prescriber ^ Method of Utilizing the System for 
CPU 7 is programmed to proceed to step 1000 described Prescription Delivery 
above. In this embodiment, the prescriber CPU 7 is programmed 

tu k jf 4k j fTTt r • *u c . c r. . 35 to transmit, via prescriber modem 12, the pauent prescrip- 

The Method of Utilizing the System for Patient # . „ . _ ™ 17 - ~, V, nrT /. - r 

r °. J tions to the server CPU 1. The server CPU 1 is also 

omp lance programmed to transmit using commercially available corn- 
In the preferred embodiment, server computer station A is munications software these patient prescriptions to the pre- 
utilized to transmit messages to the patient. These messages scrip tion delivery system D. 

will include prior notification of when and what medications 40 Prescription delivery system CPU 18 is programmed to 

the patient is scheduled to take in accordance with the retrieve drug cost data stored in its data storage UDits. This 

prescribed medical regimen. The notification could include data is then collated to the drugs contained in the prescrip- 

informing the patient of the drug name only or the drug tions in order to generate an invoice and other desired 

name and the doseage to be taken at the time the patient documentation which is then produced by printing unit 19 to 

receives the message. For example, if the patient were 45 be included with the prescriptions when delivered to the 

prescribed to take drug X three times a day, the message patient, 
"take drug X now" or "take two 250 mg tablets of drug X" 

could be transmitted to the patient three specified times ^ Method of Ut ^ lzlD g thc Svstem for 

during the day. The server CPU 1 is programmed to operate Prescription Payment 

in accordance with the procedure illustrated in FIG. 4. 50 If the patient will be the person paying for the 

Server CPU 1 is programmed in step 1101 to first deter- prescriptions, then the invoice generated by the prescription 

mine if it has received a command to stop further processing. delivery system D will be delivered to the patient. 
This command is given if a fault in the system hardware or If the payor is the patient, a healthcare payor, or govern- 

software has occurred, or if stoppage of the system is desired ment agency, the invoice generated by the prescription 

by the operator for any reason. If no halt command has been 55 delivery system D will be delivered, preferably modemed, to 

received, server CPU 1 is programmed in step 1102 to the payor system E for payment. In an alternate preferred 

perform no message delivery function for a predetermined embodiment, the invoice delivery could be conducted elec- 

period of time. This period is to allow the prescriber to more Ironically or optically. In this embodiment the invoice will 

easily and quickly access the CPU 1 to retrieve patient be transmitted through server computer station A to payor 

prescription data or pharmaceutical data, as well as to make 60 system E. This can be achieved through any number of 

and enter into the server data storage unit 2, any changes to readily available commercial communications software pro- 

the patient prescription data. This feature becomes more grams. In another alternate preferred embodiment, the pre - 

important as greater number of prescribers are connected to scription delivery system D will directly communicate by 

the server CPU 1. A preferred period of time is 30 to 60 well known linked computer systems to payor system E. 
seconds. Upon the lapse of the delay period, server CPU 1 65 A copy of a preferred software program for use with the 

is programmed in step 1103 to retrieve any messages that are system and method of this invention is set forth in Exhibit 

scheduled to be transmitted within an upcoming time period. 1 . 
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There are of course other alternate embodiments which 
are obvious from the foregoing descriptions of the invention 
which are intended to be included within the scope of the 
invention as defined by the following claims. 

What is claimed is; 5 

1. A system to facilitate compliance with a prescribed 
medical regimen comprising: 

(a) a computer system having a data storage unit capable 
of storing patient data and patient prescription data; 

(bj a central processing unit programmed and operatively ]0 
connected to said data storage unit to store said patient 
data and said patient prescription data in said data 
storage unit; 

(c) wherein said system includes a program to generate 
and transmit from a patient prescription a patient J5 
message, wherein said patient message includes a drug 

to be administered by a patient at a time of receiving 
said patient message in order that said patient complies 
with said patient prescription; 

(d) a message transmitting unit operatively connected to 
said central processing unit and transmitting said 20 
patient message at a time proximate to when said 
patient is scheduled to administer a unit dosage; and 

(e) an addressable communication device allowing said 
patient to receive said patient message transmitted from 
said transmitting unit. 25 

2. A system according to claim 1, wherein: 

(a) said data storage unit is further capable of storing 
pharmaceutical data; and 

(b) said program stored in said central processing unit 
allows comparison of said patient prescription data to 30 
said patient data and said pharmaceutical data to deter- 
mine if said patient prescription data is within recom- 
mended daily and unit dosage ranges. 

3. A system according to claim 2, wherein said determi- 
nation of whether said patient prescription data is within said 35 
recommended daily and unit dosage ranges is transmitted to 

a reporting unit. 

4. A system according to claim 2, wherein said program 
stored in said central processing unit: 

(a) allows comparison of said patient data and patient 40 
prescription data to determine if said patient prescrip- 
tion data is within a recommended prescribing duration 
range as defined by said pharmaceutical data; and 

(b) transmits the determination to a reporting unit 

5. A system according to claim 2, wherein: 45 

(a) said system includes a program to generate and 
transmit a prescription invoice; and 

(b) said system further comprises a payment system 
operatively connected to said central processing unit to 50 
receive said prescription invoice. 

6. A system according to claim 1, wherein: 

(a) said data storage unit is further capable of storing 
pharmaceutical data; and 

(b) said program stored in said central processing unit: 55 

(i) allows comparison of said patient data and patient 
prescription data to determine if said patient pre- 
scription data is within a recommended prescribing 
duration range as defined by said pharmaceutical 
data; and 60 

(ii) transmits the determination to a reporting unit. 

7. A system according to claim 1, wherein: 

(a) said system includes a program to generate and 
transmit a prescription invoice; and 

(b) said system further comprises a payment system 65 
operatively connected to said central processing unit to 
receive said prescription invoice. 



8. A system according to claim 1, further comprising a 
message receiving unit, including a modem and operatively 
connected to said transmitting unit to transmit said patient 
message to a pager. 

9. A system according to claim 8, wherein said pager is a 
two way pager. 

10. A system according to claim 1, wherein said system 
further includes: 

(a) pharmaceutical data stored in said data storage unit; 
and 

(b) said program further: 

(i) compares said patient prescription data to said 
pharmaceutical data to determine if said patient 
prescription data indicates that unacceptable drug 
interactions will occur from the drugs included 
within said medical regimen; and 

(ii) transmits the determination to a reporting unit. 

11. A system according to claim 1, wherein said system 
further includes a program to: 

(a) compare said patient prescription data to said patient 
data to determine if there were reported prior drug 
reactions to any of the drugs included within said 
medical regimen, and (b) transmit the determination to 
a reporting unit. 

12. A system according to claim 1, wherein: 

(a) said data storage unit is further capable of storing 
pharmaceutical data, including a recommended dosage 
range for at least some of the drug included in said 
pharmaceutical data; and 

(b) said program determines if said dosage is within said 
recommended dosage range and transmits the determi- 
nation to a reporting unit. 

13. A system according to claim 12 wherein if said 
program determines said dosage is not within said recom- 
mended dosage range; said program: 

(a) amends said dosage to be within said recommended 
dosage range; 

(b) transmits said amended dosage to said central pro- 
cessing unit for storage in said data storage unit; 

(c) retrieves from said data storage unit said amended 
dosage prior to the time said patient is to administer 
said drug; and 

(d) notifies said patient as to when and how much of said 
drug to administer. 

14. A system according to claim 1 wherein: 

(a) said patient data comprises: 

(i) a patient identification code used to identify said 
patient, 

(ii) data necessary to determine age of said patient, and 

(iii) a listing of other medications which said patient 
may be taking; and 

(b) said patient prescription data comprises: 

(i) a prescription identification code used to identify a 
medication to be prescribed, 

(ii) a prescription dosage of said medication to be used 
in said medical regimen, 

(iii) a duration period of taking said medication to be 
used in said medical regimen, and 

(iv) a frequency schedule of taking a prescribed amount 
of said dosage in said medical regimen. 

15. A system according to claim 1 wherein said data 
storage unit is further capable of storing pharmaceutical data 
and said pharmaceutical data comprises: 

(i) a listing of identification codes used to identify 
medications, 
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(ii) for each medication in said listing, a recommended 
dosage range, a recommended duration range, a main- 
tenance dosage range, and an acute dosage range, and 

(iii) for each medication contained in said listing, known 
interactions of each of said medications with other 5 
medications contained in said listing. 

16. A system according to claim 1 wherein: 

(a) said data storage unit is further capable of storing 
pharmaceutical data; and 

(b) said program: 

(i) compares said patient prescription data to said 
pharmaceutical data to determine if said drag to be 
prescribed has one or more known drug interactions 
with other medication said patient is taking; and 

(ii) transmits a report to a prescribing physician if a 
known drug interactions exist 
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17. A system according to claim 16, wherein said pro- 
gram: 

(a) amends said patient prescription data to eliminate said 
drug interaction if a known drug interactions exist; and 

(b) transmits said amended prescription data to said 
central processing unit. 

18. A system according to claim 1, wherein said addres- 
sable communications device is a pager. 

19. A system according to claim 1, wherein said addres- 
sable communications device is a remote communications 
device. 

20. A system according to claim 1, wherein said addres- 
sable communications device is a wireless communications 
device. 
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ABSTRACT 



An improved automated method for dispensing bulk medi- 
cations with machine-readable code. The method includes 
dispensing oral solid and liquid unit-of-use medications in 
unit dosage amounts. The medications are dispensed with 
machine-readable information which is generated as the 
medication is dispensed. The machine-readable information 
is patient- specific and can be customized to suit the needs 
of the operator. The machine-readable information can be 
used to monitor and control the medication from the lime it 
is dispensed through to the time it is taken by the patient. 

35 Claims, 26 Drawing Sheets 
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Fig.WA C start ) 

Empty Cassette is detected. 



S1 



S2 



S3 



Empty Cassette is moved to front. 

Cassette Number is notified. Wait for operator. 



Medication profile is loaded i,..,: database, 
Current inventory count and Expiration Date/ 
Lot Number are displayed on the Touch Panel. 




Operator obtains a wireless barcode 
scanner from the recharging cradle(s). 



Operator barcodes the empty cassette to verify the 
Tablet to be replenished (If wrong one is 
S5\ chosen, touchpanel will notify operator.) 

.Note:The Device ID is embedded in the barcode. 



Operator places Empty Cassette on 

Counting Scale and 

Presses the "Tare" button on the 

Touchpanel. 




S7 



Initialize the Scale for the Pieceweight and 
prompt the operator to Scan the bulk bottle 
for verification. (If wrong drug, operator is 
notified on Touch Panel.) If Correct, operator 
is prompted to pour in the desired quantity 
of medication. 




Operator pours the bulk solid orals into the 
cassette on the scale. 



S9 



Scale counts up the total medications poured 
into the cassette ( Note: A warning on the 
Touchpanel is presented if too many pills are 
put into this size cassette. ) 
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Fig. 19B 




Operator Confirms the end of the counting 
process by touching a button on the touchpanel. 



S11 



S12 



I 



Obtain and store the final quantity 
in its database. 



Prompt the operator to enter the 
Manufacturer's Lot Number and Expiration 
from the bulk source. 



S13 



Present an alphanumeric keypad on the 
touchpanel for the operator to key in the 
values. 



Operator Keys in the Manufacturer's Lot and 
S14\ Expiration Dates and confirms by touching the 
appropriate button on the Touchpanel. 



S15 



S16 



Store the new Expiration Date and 
,Lot Number in its database. 



Prompt the operator to scan the cassette 
location to verify correct return. 



Operator Scans the cassette location just 
above the motorbase where the current 
S17\ cassette is missing. If wrong location is 
scanner, Touchpanel notifies the operator. 



S18 



Operator Replaces the Cassette into the 
Cassette location and returns the wireless 
scanner to the recharging cradle. 
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Fig.20A 



S1 



S2 



S3 



( START ) 
I 



Empty ampule Cassette is 
detected. Stop the conveyor. 



Notify Cassette Number. Wait for operator. 



Medication profile is loaded from Database. 
Current inventory count and Expiration Dates / 
Lot Numbers are displayed on the Touch Panel. 




The operator obtains a wireless scanner 
from the recharging Cradle. 



Operator barcodes the empty cassette to verify the 
medication to be replenished. (If wrong one is 
S5\ chosen, touchpanel will notify operator.) 

,Note:The Device ID is embedded in the barcode. 



S6 



Prompt the operator to barcode the bulk 
source to verify the medication to be loaded. 



S7 



Prompt the operator for a total count of vials 
loaded into the cassette. ( Note: the default 
value presented is the total that fit Into the 
cassette when completely refilled.) 



S8 



S9 



The total is verified to be within expected 
limits. ( I.e. can this many vials actually fit 
into this cassette on this device ? ) 



Obtain and store the final quantity 
in its database. 
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Fig. 20 B 



sio 



Prompt the operator to enter the 
Manufacturer's Lot Number and Expiration 
from the bulk source. 



S11 



Present an alphanumeric keypad on the 
louchpanel for the operator to key in the 
values. 



Operator Keys in the Manufacturer's Lot and 
S12\ Expiration Dates and confirms by touching the 
appropriate button on the Touchpanel. 



S13 



S14 



Store the new Expiration Date and 
Lot Number in its database. 



Prompt the operator to scan the cassette 
location to verify correct return. 



Operator Scans the cassette location 
where the current cassette is missing. If 
S15\ wrong location is scanned, Touchpanel 
notifies the operator. 

I 

S16\ Operator Replaces the Cassette into the location. 



S17 



. S18 



Prompt the operator for the next cassette if 
this cassette is part of a cassette "grouping", 
( A grouping is a series of cassettes which 
contain the same drug and are automatically 
chosen if one becomes empty.) 



If Another Cassette, Repeat steps 5 through 
17 for each cassette in the same grouping. 
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PATIENT PRESCRIPTION INFORMATION 
IS TRANSMITTED TO COMPUTER 



COMPUTER ACTIVATES 
DISPENSING SYSTEM 



PATIEN". „ .-^ATIONTRAY 
IS PLACED ON CONVEYOR 



NO< 

I 



TRAY MOVES TO 
LIQUID MEDICATION 
DISPENSING UNIT 




TRAY TRAVELS TO AND IS STOPPED AT 
ORAL SOLID MEDICATION DISPENSER 



ORAL SOLID MEDICATIONS 
DISPENSED INTO TRAY IN DOSAGE 
UNIT PACKAGES WITH AFFIXED 
MACHINE-READABLE CODE 



T 




, NO 



TRAY MOVES TO AND IS 
TRAY STOPPED AT LIQUID MEDICATION 
DISPENSER. FILLED TRAY PROVIDED 

WITH MACHINE-READABLE CODE 
MOVES TO TRAY COLLECTION AREA 



T 



TRAY MOVES TO 
TRAY COLLECTION 
AREA 



MEDICATIONS ARE COLLECTED 
AT TRAY COLLECTION AREA 



Fig. 22 
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Jones, Michael 

St Luke's Pres 

Room: 4B 
Dr. Hackett 



** End of Strip ** 



AutoMed Technologies, 'nc 
888/537-3102 



I26- 
<25 



Jones. Michael 



ID : 349560199 
Location: MICU4B 



Hlli III 0 llll Hill II lllllll 
0641151035 



Jones, Michael 



FIG. 23 



10 : 349560199 
Location: MICU4B 



Sodium Chloride 



0.9% 



2ml 



• Heparin 
5000 USP units 

0.5ml 



. Sodium Chloride 
0.9% 10ml 



FIG. 24 
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AutoFill System by AutoMed Technolgies Inc. 



St. Luke's Presbyterian Hospital 
Jones, Michael 
MICU 4B 
Order #: 



11/08/1998 17:13 
Fill For: 11/08/99 
-I28 



Page 1 of 1 

^ 101 

ID: 349560199 



Injectable Medications from AutoFill 



Checked By 



Sodium Chloride 0.9% (0.308 milliosmois/mL) 
Quantity: 1 
Give at" ~? am 



Heparin Sodium 5,000 (JSP 0.5 ml 
Quantity: 1 
Give at noon 



Sodium Chloride 0.9% (0.308 milliosmois/mL) 

Quantity: 1 

Give at before bed 



2 ml 




10ml 



Oral Solid Medications from AutoFill 



Checked By 



M&Ms packets: 3 (Quantity: 1 per Bag) 

Give at 10:00 am, 4:00 pm and 10:00 pm \^ 

Skittles packets: 1 (Quantity: 2 per Bag) 
Give at 10:00 am 

TicTacs packets: 2 (Quantity: 1 per Bag) 
Give at 10:00 am. 10:00 pm 




Medications to be Manually Picked 
None 



Checked By 



Total: 6 med packets, 3 injectables, 0 Manual Items 

FIG. 25 
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AUTOMATED METHOD FOR DISPENSING 
BULK MEDICATIONS WITH A MACHINE- 
READABLE CODE 

FIELD OF THE INVENTION 

This invention is related generally to automated dispens- 
ing technology and, more specifically, to an improved 
method for bulk dispensing of medication including infor- 
mation used to control and track patient medication orders. 

BACKGROUND OF THE INVENTION 

Automated dispensing of prescription medications, such 
as oral solid pills and liquid unit-of use ampules, is a 
well-known method of filling dosage-based prescriptions. 
Dosage-based prescriptions are filled in a way which orga- 
nizes Ihe medication into one or more dosage units by, for 
example, the lime of day at which the medication is to be 
taken or the sequence in which (he medication is to be taken. 
Dosage-based automated medication dispensing systems 
have particular utility in settings where large amounts of 
such prescription medications are required. Hospital formu- 
laries are ideal candidates for use of such dispensing sys- 
tems. However, other businesses, such as mail order pre- 
scription filling services and pharmacies, can also use these 
systems. 

Automated medication dispensing devices typically 
include one or more computer-controlled dispensing 
machines which store and dispense medications according to 
patient-specific prescription information. These automated 
medication dispensing devices offer many advantages. 
These advantages include the ability to store a broad range 
of prescription medications and the ability to fill patient 
prescriptions in a rapid and efficient manner. In addition, use 
of automated prescription filling equipment reduces the 
possibility of human error in filling patient prescriptions. 
Another advantage is that the cost savings from automated 
dispensing of medications can be used to employ more 
pharmacists and care givers who can provide personalized 
service to patients. 

However, automated medication dispensing systems 
which attempt to dispense on a dosage unit basis have 
significant disadvantages. For example, certain dosage 
based systems are unable to fully utilize bulk medication 
dispensing technology. Bulk dispensing of medications 
involves the storage of pills or unit-of-use medications in 
bulk, for example in bins, magazines or canisters. The 
bulk-dispensed medications may be dispensed into contain- 
ers according to patient -specific prescription information. As 
can be appreciated, bulk dispensing is most efficient when 
the medication is stored in a raw, non-prepackaged form 
since this permits great flexibility in the type of medications 
which can be dispensed and because the medications can be 
rapidly replenished in the bulk storage containers. Bulk 
dispensing becomes even more advantageous as the number 
and type of medications dispensed is expanded. For 
example, a hospital formulary is required to dispense dosage 
units of many different solid and liquid medications; an 
effective bulk dispensing system would be a particularly 
useful way to manage and control the distribution of such a 
diverse range of medications. 

However, most prior art systems which provide dosage- 
based dispensing are required to store individual pills or 
medications in individual unit dosage packages and not in 
bulk. These separate unit dasage packages are stored within 
the dispensing device and must be separately retrieved to fill 
a patient's order. This is disadvantageous because it is 
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difficult to arrange, customize and/or mix the pills compris- 
;. >£> '..e patient's unit dosage. The process also requires 
time-consuming and expensive prepackaging of the medi- 
cations to be dispensed. Such dosage-based systems arc 
unable to realize the flexibility and cost savings benefits of 
bulk dispensing. 

Another disadvantage of certain prior art dosage-based 
medication dispensing systems is that it is difficult to fully 
control and track the individual dosage units. The prepack- 
aged dosage units used by these companies have preprinted 
information on (he packages which is generic in nature and 
is not generated for the specific patient as the medication is 
dispensed. Such preprinted information might include 
National Drut; Code ("NDC") information and a code for the 
stor.._._ .... n of the dosage unit within the dispensing. 
This information is limited and leaves little room for appli- 
cation of more patient-specific information such as the 
patient's name and other information which directly links 
the patient to the dosage unit. The Homerus system from 
Cardinal Health Care and the Robot Rx system from 
McKesson are representative dosage-based dispensers 
which include the foregoing disadvantages. 

There are many potentially useful applications for the 
patient-specific information. For example, this information 
can be used at the completion of the filling process to verify 
that the correct medication has been supplied to the patient. 
The information could be used at the patient's bedside to 
create a record of the medication taken by the patient 
including the type and quantity of medication taken and the 
time of day at which the medication was taken. Patient- 
specific information on the medication packages could even 
be used for purposes of billing. 

It would be a significant improvement in the art to provide 
an automated method for dispensing bulk medications in 
dosage form with real-time-generated machine-readable 
code so that the medication could be associated with a 
specific patient. 

OBJECTS OF THE INVENTION 

U is an object of this invention to provide an improved 
automated method of dispensing bulk medications overcom- 
ing problems and shortcomings of the prior art. 

Another object of this invention is to provide an improved 
automated method of dispensing bulk medications with 
patient-specific machine-readable code affixed to Ihe medi- 
cation packaging. 

It is also an object of this invention is to provide an 
improved automated method of dispensing bulk medications 
in which the machine-readable code affixed to the medica- 
tion packaging can be used for many purposes including, 
without limitation, for verification that the order is correct 
and complete, for compliance with dosage protocols and for 
billing. 

Another object of this invention is to provide an improved 
automated method of dispensing bulk medications in which 
patient -specific machine-readable code is affixed to the 
medication packaging in real time as the medication is 
dispensed. 

A further object of this invention is to provide an 
improved automated method of dispensing bulk medications 
in which the prescriptions can be filled rapidly and eco- 
nomically. 

Yet another object is to provide an improved automated 
method of dispensing bulk medications which avoids costly 
and time-consuming prepackaging steps. 
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An additional object of this invention is lo provide an 
improved automated method of dispensing bulk medications 
which can be used with a wide range of medications 
including oral solid medications and unit-of-use liquid medi- 
cations and other types of unit-of-use products. 

How these and other objects are accomplished will be 
apparent from the descriptions of this invention which 
follow. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The following description of an embodiment of the 
present invention is carried out with reference to the accom- 
panying drawings, in which: 

FIG. 1 is a schematic view of a medication collecting 
system according to an embodiment of the invention; 

FIG. 2 A is a front view of an initial state showing the tray 
discharging structure of the tray feed station, and 

FIG. 2B is a front view in which the lowermost tray is 
discharged; 

FIG. 3 is a partly broken perspective view showing the 
tablet dispensing station of FIG. 1; 

FIG. 4 is a front view showing the cutter part of the tablet 
dispensing station of FIG. 3; 

FIG. 5 is a perspective view showing the direction chang- 
ing part of the tablet dispensing station of FIG. 3; 

FIG. 6 is a front sectional view showing the conveyor of 
the tablet dispensing station of FIG. 3; 

FIG. 7 is a perspective view showing the package-belt ■ 
bundling section shown in FIG. 1; 

FIG. 8 is a perspective view showing the distributing 
member of the package-belt bundling section of FIG. 7; 

FIG. 9 is a side sectional view of the distributing member 
of the package-belt bundling section of FIG. 8; 

FIG. 10 is a partly broken perspective view showing the 
array ampule dispensing station of FIG. 1; 

FIG. 11 A is a front sectional view showing the ampule 
cassette of FIG. 10, 

FIG. 11B is a partial sectional view showing an ampule 
discharging state including a slop provided in a lowermost 
portion of the ampule cassette, and 

FIG. UC is a partial sectional view showing an ampule- 
holding stale including the stop; 

FIG. 12 is a partly broken perspective view showing the 
random ampule dispensing station; 

FIG. 13A is a front sectional view showing the ampule 
container of FIG. 12, and 

FIG. 13B is a lop sectional view showing the ampule 
container of FIG. 12; 

FIG. 14 is a sectional view showing the lifter part of FIG. 
12; 

FIG. 15A is a sectional view showing the lifter container 
of the lifter part of FIG. 14 with its bottom plates released 
from the closed state, and 

FIG. 15B is a sectional view showing a stale in which the 
lifter container has been elevated from the position shown in 
FIG. 15A; 

FIG. 16 is a schematic perspective view showing the label 
issuing station of FIG. 1; 

FIG. 17 is a sectional view showing the tray recovering 
station of FIG. 1; 

FIGS. 18A and lflB are front views showing examples of 
the package belt in which medicaments are packed; 



FIGS. 19A and 19B are flow charts showing ihe tablet 
replenishing work in the tablet dispensing station; 

FIGS. 20A and 20B are flow charts showing the ampule 
replenishing work in the array ampule dispensing station or 
random ampule dispensing station; 

FIG. 21 is a schematic sectional view of automatic 
packing station that can be provided instead of the tray 
recovering station of FIG. 17; 

FIG. 22 is a flow diagram of a preferred embodiment of 
10 the invention; 

FIG. 23 is an example of an oral solid medication package 
including machine- readable code. 

FIG. 24 is an example of machine-readable code labels for 
15 use with unit-of-use products such as liquid medications; 
and 

FIG. 25 is an example of an instruction sheet which can 
be dispensed with the medication including dosage instruc- 
tions and machine-readable code information. 

20 SUMMARY OF THE INVENTION 

The method provides an improved manner of dispensing 
bulk meH ; 'Mens into dosage units together with machine- 
readable drug prescription information that can be used to 
25 control and track patient medication orders. The machine- 
readable code may be affixed to the medication packaging in 
real lime as the medication is dispensed so as to directly link 
a dosage unit to a specific patient. The machine-readable 
code may be creatively configured to include any suitable 
30 information such as the patient name and dosage instruc- 
tions. Use of bulk dispensing is fast, economical and permits 
the dosage units to be customized to the requirements of the 
patient both with respect to the type of medications and the 
ordering of the medications for consumption by the patient. 
35 The machine-readable patient information can be used for 
many purposes incident to the actual dispensing of the 
medication. 

In general, the method comprises the initial step of 
providing at least one person's drug prescription information 
dc to a computer for controlling one or more bulk medication 
dispensing devices. The bulk dispensing device or devices 
used in the method automatically dispense and package a 
predetermined quantity of solid medication into at least one 
dosage unit in response lo a signal from ihe computer based 
45 on the person's drug prescription information. The dispens- 
ing device or devices automatically apply machine-readable 
drug prescription information to the solid medication pack- 
age in response lo a signal from the computer based on the 
drug prescription information. 
so The dispensing apparatus used in the method can also 
automatically dispense a predetermined quantity of pack- 
aged liquid medication from a second bulk dispensing 
apparatus in response to a signal from the computer based on 
the person's drug prescript,' information. The apparatus 
55 automatically provides machine-readable drug prescription 
information for application to the liquid medication package 
in response lo a signal from the computer based on the drug 
prescription information. The packaged unit dosage pack- 
ages are collected together with the machine-readable infor- 
60 mation so that the medication can be distributed to the 
person 

Additional aspects of the method are explained in the 
detailed description which follows. 

65 DETAILED DESCRIPTION 

FIG. 1 shows a preferred embodiment of the apparatus 
used to perform many of the steps of the inventive method. 
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The apparatus is available from AutoMed Tech nologies, Inc. The tablet feed section 14 comprises a cylindrical drum 

of Vemon Hills, 111. and is sold commercially as the AutoFill L8 equipped with inner and outer tablet guide parts 17 which 

System. One embodiment of such apparatus is descr,,,. i in extend up and down. The tablet feed section 14 comprises a 

U.S. patent application Scr. No. 09/205861, now U.S. Pat. plurality of motor bases 19 disposed vertically and circum- 

No. 6,170,230 (Chudy et al.), the contents of which are S ferentially on the outer periphery of each tablet guide part 

incorporated herein by reference. 17, and a plurality of bulk storage tablet cassettes removably 

The exemplary medication dispensing system 200 shown attached to the motor bases, respectively. Each tablet guide 
in FIG. 1 includes a tablet dispensing station 4 an array part 17 is divided circumferentially for each column of the 
ampule dispensing station 5, a random ampule dispensing vertically arrayed motor bases 19 and tablet cassettes 20, by 
station 6 and a label issuing station 7. These dispensers are 10 which a tablet guide passage 21 extending vertically is 
disposed one after another along a conveyor line 3 that formed. Below the cylindrical drum 18, are disposed hop- 
connects a tray feed station 1 and a tray recovering station pers 22a, 22b r which make it possible to collect tablets 23 
2 to each other. uropping via the tablet guide passages 21 to one place. 

These components are modular and can be configL^o and In the tablet cassettes 20, different types of tablets 23 are 

arranged to meet the needs of a specific operator. For 15 stored, respectively, and tablets 23 amounting to one-day 

example, additional tablet dispensing devices (such as tablet doses are discharged in units of one dose based on prescrip- 

dispensing station 4) could be added to the system 200 as <ion information. This arrangement permits the operator to 

could additional ampule dispensing stations (such as ampule bulk store and dispense a broad range of tablets 23. The 

dispensing stations 5 and 6). discharged tablets 23 are counted by sensors (not shown) 

Conveyor line 3 need not be linear and can be configured 20 provided on the motor bases 19, and fed to the printing and 

to meet the space requirements of the particular operator. packaging section 15 via the hoppers 22 through the tablet 

Additional stations (not shown) can be added along the * uidc P 3 ?^ 8 21 Thc numbcr of tablets fch in a toWel 

conveyor line. These stations might include automated unit- ca ^ sette 2 ° can be oounled based on the initial " ,imber of 

of-use dispensing devices for dispensing products such as ,< P lUs storcd and tbe ™ unt numbcr ^ the xnso ^ aliowin £ a 

decision as to whether or not the tablets 23 in cassette 20 



intravenous solutions. In addition, stations consisting of 



pick-to-light storage shelf systems and non-automated stor- havc becn de P lctecj - 

age shelf systems can be disposed along conveyor line 3 to The printing and packaging section 15 comprises a roll 24 

provide an opportunity to place additional products and on which the package belt is wound, a printing part 25 for 

items into receptacles, shown as trays 9. 3Q applying specified print on the surface of the package belt 

We now turn to a more specific description of a preferred l3 ' a seaHn B P art 26 for seaIin B lhe Package bell 13 in doses, 

embodiment of the dispensing apparatus used to practice an and a cutter P art 27 for cutlin S tne package belt 13 into 

example of the method. specified lengths. 

The cutter part 27, as shown in FIG. 4, comprises a 

Tray Feed Station ^ circular cutter 29 provided so as to be movable up and down 

The tray feed station 1 is shown generally in FIG. 1. A aIon S a S uidc shaft ^ and a P iv <*al cutter guide 30 which 

plurality of trays 9 are stored in tray feed station 1 in a has a recess for gu^fi &e peripheral cutting edge of 

stacked state within a cylindrical housing 8 having a reel- thc cuttcr 29 and which LS P Ivotal abou! a P ivot 30fl provided 

angular cross section as shown in FIG. 2A. Tray feed station at an u PP er encK A rod 32 of a solenoid 31 is coupled to a 

1 is enabled to feed out the (rays 9 one by one. The housing 40 lower cnd P ortlon of thc cutter £ uidc 30 so tnat lhc cuttcr 

8 has, on its opposite sides, support feed claws 10 which are S uide 30 can be P ut int0 adjacency to the package belt 13, 

pivoted by an unshown motor or the like, respectively. The facilitating cutting by the cutler 29. 

support feed claws 10 support peripheries of the lowermost The package-belt bundling section 16 is provided to 

tray 9 by their lower claw portions 10a and, by pivoting, bundle and bind the package belt 13 cut by the cutter 29. To 

place the lowermost tray 9 onto a feed-out plate 11 located 45 lhis package-belt bundling section 16, the package belt 13 is 

below the lowermost tray 9. During this process, the support fed v * a a direction changing part 33 and a conveyor 34. 

feed claws 10 support peripheries of the next tray 9 by their The direction changing part 33, as shown in FIG. 5, is 

upper claw portions U)b as shown in FIG. 2B, thereby provided to turn the cut package bell 13 approximately 90 

making it possible to take out only the lowermost tray 9. In degrees (from generally vertical to generally horizontal) 

addition, the support feed claws 10. after taking out the 5c while conveying the package bell 13 in a left to right 

lowermost tray 9, return to the original position and support direction in FIG. 5. This direction changing part 33 com- 

the next tray 9 by their lower claw portions 10a. The prises a guide member 35 for guiding the package belt 13, 

feed-out plate 11, which is guided by a lower opposite face a guide plate 36 for guiding the lower edge of the package 

of the housing 8, can be moved up and down by a motor or bell 13 lo the guide member 35, and a wire 37 for gradually 

the like. This feed-out plate 11 has a plurality of rotation- 55 holding the upper edge of the package bell 13 to tilt package 

drivable rollers 12 provided in parallel. In the lower opcr- belt 13 sideways. 

aling position, the feed-out plate U is enabled to trans- The conveyor 34, as shown in FIG. 6, is enabled to convey 

versely convey lhe tray 9 placed through a lower opening of the package belt 13 obliquely upward by a horizontal 

the housing 8 and feed out the iray 9 to the conveyor line 3. conveyor belt 38 and a sloped conveyor belt 39. A tension 

_ , t _ 60 sheet 40 is disposed above part of the horizontal conveyor 

Tablet Dispensing Station beU 38 and ^ sfoped conveyof Ml 39. This tension sheet 

The tablet dispensing station 4 shown in FIGS. 1 and 3 is 40 is formed of a flexible material having small frictional 

provided to store bulk-form tablets 23 and to pack tablets 23 resistance. A sponge roller 41 is pivotally-mounted on the 

into a strip-shaped package belt 13 in doses. Tablet dispens- entrance side of an insertion passage defined by the belt 38 

ing station 4, comprises a tablet feed section 14, a printing 65 and the tension sheet 40. The bell 38 is set to a conveyance 

and packaging section 15 and a package-belt bundling speed higher than thai in the direction changing pari 33. If 

section 16 (See FIG. 1). an unreasonable tensile force should act upon the package 
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belt 13, an unshown limit switch is turned off by the conveying section 65 and an ampule dispensing section 66, 
swinging movement of Ihe sponge roller 41 so that the and is used mainly to dispense ampules 67 each having a 

driving of the belt 38 is stopped. Meanwhile, on the exit side large capacity as much is 10 to 30 ml (for more details, see 

of the insertion passage, a presser member 42 biased by a Japanese Patent Laid-Open Publication HE! 7-267370). 

spring is provided, bir.sing the tension sheet 40 toward the s In thc ampulc storagc scctiorj H a pluraIity 0 f drawcr 

belt 39. As a result, the package belt 13 is pressed aeainst the „ ., T . , /, rtf 

t- i. io .i f* * * i * • , • i .1 cradles 68 are provided in array. In each drawer cradle 68, 

belt 38 with the fnctional resistance increased, so that the . . . - r , „ A . , , . c , 

package belt 13 can be prevented from clogging on the exit a of f ( m P u Q lc cas f cttcs 69 1 * 

side. In addition, reference numeral 43 denotes a delivery f m P u L le cassette 69 > * s J*)™ n "J ^ ^ * shaped into a 

belt to deliver package belt 13 to thc package-belt bundling in box ^ving an open able/clos able door 70 provided on one 

section 16 side ^ ace - Insidet h e cassette 69, the ampules 67 are stored in 

The package-belt bundling section 16, as shown in FIGS. a laterally-postured and arrayed state Also, as shown in 

7 and 8, comprises an inverting member 44, a lifter 45, a FIGS - 18 and llC > the lower face of lhe am P uI& cassettc 69 

feed-in member 46, a bundling machine 47 and a distribut- 15 openedand a slop 71 is provided at the opening so as to 

ing member 48. prevent the ampules 67 from falling out. When the ampule 

The inverting pi . - • is supported so as to be rccip- 15 cassette 69 is set U P- onI y the lowermost-positioned ampule 
rocally pivotal over a range of approximately 180 degrees ^ can be discharged in a downward direction by withdraw- 
about a support shaft 44a. This inverting member 44 com- ing st0 P 71. Further, handles 72, each protruding in a 
prises a pull-in conveyor 49 for pulling in the package belt generally L shape are formed above and below on one side 
13 from the delivery belt 43. A stopper 50 for positioning the face of the ampule cassette 69 perpendicular to the door 70. 
conveyed-in package belt 13 is protrusively provided at an 20 A detent actuator portion 72a is formed in the lower handle 
end portion of the pull-in conveyor 49. A sensor (not shown) 72, so that an engaging detent 12b provided at the lower end 
is provided in proximity to the stopper 50 so that the surface of thc ampule cassette 69 can be operated to extend 
presence or absence of the package belt 13 can be delected. and retract. By this engaging detent, the ampule cassette 69 

The lifter 45 is plate-shaped and has a side wall 45a can be attached to the drawer cradle 68. The drawer cradle 

extending along both side edge portions, and a recess 456 25 68 is equipped with discharge rotors 73, and the ampules 67 

extending longitudinally in a central portion. The lifter 45 is within the ampule cassette 69 can be discharged one by one 

reciprocally moved between a lower position where the fc y t ^ t discharge rotor 73 pivoting between the states of 

package belt 13 is inverted by the inverting member 44 and FIGS UB and UA In addilioD , an insertion hole (not 

can be loaded, and an upper position where the package belt shown) intended for a sensof is bored in ^ Iower . end side 

13 can be conveyed to the bundling machine 47 by the 30 surface of ^ ampule 69 making {{ possiMc tQ 

il -1 " me 1 m \ „ , , . , , , determine whether the remaining stock of ampules 67 has 

•H» feed-in member 46 has a brush 52 provided at an end been decreased or has been d leted> 
oi a reed-in arm 51 that reciprocally moves along the side 

portion 45a of the lifter 45 located in the upper position. ^ am P uIe conveying section 65 comprises a first con- 

The bundling machine 47 comprises a looped rectangular 35 vc y° r bclt 74 dis P oscd bclow thc drawcr cradIc 68 ' a stock 

frame body 53, and a roller 55 on which bundling tape 54 is stora S e 75 provided at the conveyance end of the first 

wound, where the central part of the stacked package bell 13 conveyor belt 74, and a second conveyor belt 76 disposed 

can be bundled with the tape 54 unwound from the roller 55. below the stock storage 75 generally perpendicular to the 

A chute 56 is provided in proximity to the bundling machine first conveyor belt 74. 

47 along which the package belt 13 is discharged. This chute The ampule dispensing section 66 comprises a stock 

56 has a lip end directed obliquely upward prior to discharge container 77 for storing conveyed ampules 67, and an 

of the package belt 13. A presser 46fl of the feed-in member up-down member 78 for discharging the ampules 67 stored 

46, presses a lever 56a, by which the chute 56 is pivoted and in con tainer 77 to the trav 9 on the conveyor line 3 while 

directed obliquely downward to discharge the package belt supprcss j ng any impact force acting on the ampules 67. 

The distributing member 48, as shown in FIG. 8, has an 4f Random Ampule Dispensing Station 

opening 58 formed in a sloped plate 57 directed obliquely ~ t ... • . .• * u 

/ b . , . . . ^„ . , . , . , The random ampule dispensing station 6, as shown in 

downward, and this opening 58 is opened and closed by a , r , r , , , . - ft 

j. en A , ■ , i.*«t_ i i | — _ FIG. 12, comprises a drum-shaped rotary storage rack 79, 

distributing plate 59. A lower end edge ot the sloped plate 57 . * \ on . ^ i • .? . e 

. , , .u i- i n • . ■ I it j . and a lilter part 80 which goes up and down in the center of 

extends lo the conveyor line 3, allowing the bundled pack- ... V t in a • i . j- - f 

J » , n . , r c . lhe rotary storage rack 79, and is used to dispense mainly 

age belt 13 to be accommodated in the tray 9. Also, a first - (j ., • t>* . -*\ -. L * 

r b . . . . , . ... small-capacity ampules 81 (FIG. 13) with a capacity less 

link 60 is pivotally coupled at its one end portion to the . 1rt i ,/ i . -r t n . . a r 

, . , , fft , . n a • | - | j- » than 10 ml (for more details, see Japanese Patent Apphca- 

distnbuting plate 59 as shown in FIG. 9. A second link 62 . , . „ . . n . Qn ,, r i mnnnni un n i a^a-^i nn 

. . . to \, i . . r. c . t+ n Hons HEI 10-149489, HEI 10-99001, HEI 9-142473, HEI 

provided on (he rotating shaft of a motor 61 is pivolally ^ ?p](p elc ) 

coupled to the other end portion of the first link 60. The "* e *' 

motor 61 is so designed as to stop after every 180 degree ^ In the rotary storagc rack 79, a plurality ot ampule 

rotation. As a result of this, the distributing plate 59 is containers 82 are disposed vertically and circumferentially 

pivotal between one position where the distributing plate 59 in 50 lhal an up-™d-down space for the litter part 80 10 can 

is aligned with the sloped plate 57 with the lower edge be oblained on tne central Slde ' Each ara P uIe conlainer 82 > 

slightly out of alignment with the top surface, and another as showD in FlG ^ l3A and ^"iprises an ampule 

position where the distributing plate 59 is positioned gen- 60 stora S e chamber 83 and an am P uIe array-and-conveyance 

erally vertical. Also, a dust box 63 is disposed below the seclion 84 ' ^ am P u,es are ^-stored within storage 

opening 58 of the sloped plate 57, so as to collect unnec- chamber 83 prior to dispensing. Different types of medica- 

essary portions (empty packages) of the package belt 13. lions can be <^pensed in lhe form of ampules 81 giving the 

operator flexibility in filling prescriptions. 

Array Ampule Dispensing Station 65 A bottom waH 85 of the am p ule storage chamber g 3 is 

The array ampule dispensing station 5, as shown in FIG. pivotal about a pivot 85a, and will be inclined by rotation of 

10, comprises an ampule bulk storage section 64, an ampule a rotating arm 86 so that the ampules 81 can be moved to the 
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ampule array -and -conveyance section 84. Also, in the 
ampule array-and-conveyance section 84, a belt 88 is 
stretched between pulleys 87 so that the ampules 81 placed 
on the belt 88 can be conveyed by one pulley 87 being 
rotated by the drive of a motor 87a. The ampule array-and- s 
conveyance section 84 can be moved up and down by the 
drive of a motor, between a lower position where the 
ampules 81 within the ampule storage chamber 83 can be 
loaded on, and an upper position where the ampules 81 can 
be discharged to the lifter part 80 via a chute 83a. In io 
addition, the ampule storage chamber 83 and the ampule 
array-and-conveyance section 84 are partitioned from each 
other by a shutter 836, which is opened and closed with a 
pinion 83c and a rack 83a*. 

In the lifter part 80, as shown in FIGS. 12 and 14, a lifter ^ 
container 90 is moved up and down along three rails 89 
provided vertically in a center-side space of the rotary 
storage rack 79 (for more details, see Japanese Patent 
Application HEI 9-3071530) The lifter container 90 is 
funnel-shaped and has spiral guide blades 91 formed therein. 20 
The lifter container 90 is rotated by an unshown motor and 
guide blades 91 direct an ampule 67 to a central opening 92 
under the guide by the guide blades 91. The opening 92 is 
opened and closed by an opening/closing valve 94 that is 
moved up and down with an opening/closing arm 93. 25 

A delivery stock storage device 95 is provided below the 
lifter container 90. As shown in FIG. 15A, device 95 
includes pivotally-mounted bottom plates 96. Each bottom 
plate 96 is pivotal about a pivot 96a to form an opening 97 
in the bottom of device 95 when in the position shown in 30 
FIG. 15B. The bottom plates 96, as shown in FIG. 14, 
receive the ampules 6-7 from the lifter container 90, and 
keep the bottom -face opening 97 closed by links 98 until the 
bottom plates 96 are located above and near the tray 9. Then, 
when the bottom plates 96 are located above and near the 35 
tray 9, the bottom plates 96 are released from the closed state 
by the links 98, as shown in FIG. 15A. As a result, when the 
lifter container 90 is moved up relative to the tray 9, the 
bottom plates 96 pivot while keeping their free end portions 
in contact with the top face of the tray 9, gradually opening dC 
the opening 97 as shown in FIG. 15B. Accordingly, the 
ampules 67 discharged from the lifter container 90 are 
smoothly moved into the tray 9 without undergoing any 
impact force. 

Label Issuing Station 

The label issuing station 7 has a plurality of printers 99a, 
99 b arranged vertically as shown in FIG. 16, and the 
uppermost three printers 99a arc fed with prescription paper 5G 
101 from slock store 100, respectively. This prescription 
paper 101 is provided so that a pharmacist may verify that 
the correct medication was dispensed. Also, the two printers 
99b (shown juxtaposed below printers 99a) are each fed 
with labels, such aslaber 103, wound around a roll M)2.This 5 c 
label 103 is affixed to the ampules 67, storage containers or 
the like, and is used to indicate their contents. Machine- 
readable information, such as bar code information, is 
printed oo paper 101 and labels 103 as described elsewhere 
in the application. 60 

Tray Recovering Station 

In the tray recovering station 2, as shown in FIG. 17, a 
support base 106 is provided on rails 105 placed above and 
below in a support main frame 104 so that the support base 65 
106 is reciprocally movable along an X-axis direction par- 
allel to the conveyor line 3. The support base 106 is 



equipped with guide rails 107 extending vertically. Base 
108a movable up and down along guide rails 107 in a 
vertical Y-axis direction by a belt chain 108. Base 108a is 
equipped with a cylinder 109. Rod 109a of the cylinder 109 
is equipped with a gripping arm 110, which goes back and 
forth along a Z-axis direction perpendicular to the conveyor 
line 3. The gripping arm 110 has at its front end a claw 
portion 10a formed for gripping a peripheral portion of the 
tray 9 (see also Japanese Patent Laid-Open Publication HE 
9-51922 etc.). 

System Operation 

N«*vt operation of the exemplary medication collecting 
system constructed as described above is explained. 

When patient prescription information is read, a tray 9 is 
fed out from the tray feed station 1 to the conveyor line 3. 
The tray 9 fed out to the conveyor line 3 is first conveyed to 
the tablet dispensing station 4. If the patient's prescription 
information does not include tablets 23, the tray 9 passes ■ 
tiiRtugh the tablet dispensing station 4 without stopping. If 
tablet 23 information is included in the prescription, the tray 
9 is stopped below the sloped plate 57 of the distributing 
nv '-48. 

Tablet dispensing station 4 then dispenses tablets 23 in 
dosage units, such as one-day doses of medicaments. The 
tablets are fed from the relevant tablet cassette 20 in steps of 
one dose one after another according to the dosage time, and 
then are packed into medication packages formed in the 
package belt 13. 

As for the form of package, if a one-day dosage includes 
a plurality of times, for example, morning, noon and 
evening, then medication packages 13a of the tablets 23 are 
continuously packaged as shown in FIG. 18A, or empty 
packages are formed between the medication packages 13a 
of the tablets 23 and the contents of the tablets 23. Dosage 
information and the like are printed on these empty packages 
to make printed portions 13/? as shown in FIG. 18B. (Dosage 
information can also be printed on the packages containing 
tablets 23 as is the case in the package 13 shown in FIG. 23.) 
In the former case, as shown in FIG. 18A, the package belt 
is cut off by the cutter 29 with one-day doses taken as a unit. 
Thus, the need for bundling by the bundling machine 47 is 
eliminated. In the latter case, as shown in FIG. 18B, the 
package belt is cut off by the cutter 29 with one dose taken 
as a unit. In addition, with a different patient, two empty 
packages 13c are additionally formed between a printed 
portion 13b for patient A and a medication package portion 
13a for the next patient B, thus enabling continuous pro- 
cessing. Further, the empty packages I3c are separated from 
the other portions by the cutter 29. 

Subsequently, the cut package belt 13 is conveyed to the 
inverting member 44 via the direction changing part 33 and 
the conveyor 34, so as to be transferred to the lifter 45. For 
the package bell 13 or the empty packages 13c in the unit of 
one -day doses, the lifter 45 goes up without waiting for 
stacking by the transfer from the inverting member 44; for 
the package belt 13 in the unit of one dose, the lifter 45 will 
not go up until the one-day doses have been completely 
stacked by the transfer from the inverting member 44. Then, 
the cut package belt 13 is moved sideways by the feed-in 
member 46, where in the case of the package belt 13 or 
empty packages 13c in the unit of one-day doses, the cut 
package belt 13 is passed through as it is without being 
bundled by the bundling machine 47; in the case of the 
stacked package belt 13, the cut package belt 13 is once 
stopped at the bundling machine 47, where the cut package 
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belt 13 is bundled and ihen fed to the tray 9 via the 
distributing member 48. In addition, in the districting 
member 48, for processing's sake, when empty packages 
13c are conveyed up, the empty packages 13c are discarded 
to the dust box 63 via the opening 58 by rotating the 
distributing plate 59. 

Subsequently, the tray 9 is conveyed to the array ampule 
dispensing station 5, and further to the random ampule 
dispensing station 6. In this case also, based on the prescrip- 
tion information, the tray 9 is passed through as it is, or when 
ampules 67, 81 are fed, the tray 9 is stopped at a relevant 
unit. 

After that, the tray 9 is conveyed to the label issuing 
station 7. In the label issuing station 7, the prescription paper 
101 on which prescription information as to all the medi- 
caments within the conveyed-up tray 9 has been p ' 1 
well as a label 103 to be affixed to the surface to sh.... ine 
contents of the stored ampules 67, are fed into the tray 9. 

Now that desired medicaments have been fed to the tray 
9 in this way, this tray 9 is conveyed to the tray recovering 
station 2, where the medicaments are transferred onto 
shelves of a sorting cart (e.g., medication storage cabinet 
marketed by Pyxis Co.) C by the arm 110. In addition, this 
sorting cart C is movably set in the nurse station, and put into 
use for distribution to the patients in hospital when the time 
to administer the medication has arrived. 
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Medication Replenishment Operation 

Whereas the dispensing of medication is carried out as 
described above, the medication collecting system can 
detect the absence of any tablets 23 and ampules 67, 81, and 
can perform appropriate replenishment by checking these 
medicaments. 

For this purpose, the tablet dispensing station 4 and the 
ampule dispensing stations 5, 6 are equipped, although not 
shown, with a touch panel to be controlled by a controller, 
a wireless bar code reader with a recharging cradle therefor, 
and a scale. 

In the tablet dispensing station 4, the tablet cassettes 20 
are exchanged according to the flow charts of FIGS. 1 9 A and 
19B. That is, when specified tablets 23 have come out of 
stock so that an empty tablet cassette 20 is detected (step SI) 
, the cylindrical drum 18 is rotated so that the empty tablet 
cassette 20 is moved to an interchangeable position, where 
its cassette number is notified, followed by a standby state 
(step S2). Also, a relevant medication profile is loaded from 
the database, and the current inventory count and expiration 
dates/lot numbers are displayed on the touch panel (step S3). 
Then, the operator obtains a wireless bar code scanner (step 
S4), reads the bar code of this tablet cassette 20, verifying 
tablets 23 to be replenished (step S5) In this process, if the 
selected tablet cassette 20 is other than one containing the 
correct tablets 23, the operator is informed of an error by the 
touch panel. 

Subsequently, the operator places the empty tablet cas- 
sette 20 on the scale, where if the operator presses the "Tare" 
button on the touch pane] (step S6), then the scale is 
initialized, prompting the operator to operate the bulk bottle 
for verification (step ST). If the verified bulk bottle is 
erroneous, the result is displayed on the touch panel, thereby 
notifying the operator of the error. If the verification result 
is correct, then the operator is prompted to pour in a desired 
quantity of medication into the scale. Then, if the operator 
has poured oral medication into the tablet cassette 20 on the 
scale (step S8), the scale counts the total medications poured 
into the tablet cassette 20 (step S9) In this case, if too much i 
medication is poured in, a warning is presented on the touch 
panel. 



Next, the operator operates a button on the touch panel, 
where if an end of the counting process is confirmed (step 
M0), then the final quantity is stored in the database (step 
Sll ). Subsequently, the operator is prompted to enter the 
manufacturer's lot number and expiration date according to 
the indication on the bulk bottle (step S12). Also, an alpha- 
numeric keypad is displayed on the touch panel for the 
operator to key in values (step S13). If the operator has 
keyed in the manufacturer's lot number and expiration date 
and confirmed by touching an appropriate button on the 
touch panel (step S14), then the database is updated so that 
the lot number and expiration date are rewritten to the new 
ones (step S15). 

After that, in order to verify a correct return place for the 
replaced tablet cassette 20, the operator is prompted to scan 
the bar code of cassette location (step SI 6), and this is 
displayed on the touch panel. The operator sets a new tablet 
cassette according to this instruction, where the operator 
scans the bar code of the cassette location provided just 
1 above the motor base 19 with no tablet cassette 20 set. If a 
barcode of a wrong position is scanned, this fact is displayed 
on the touch panel so that the operator is notified of it (step 
S17). With these steps of work completed, the operator sets 
the tablet cassette 20 to the motor base 19 in the correspond- 
ing position, and returns the wireless scanner to the original 
position (step SI 8). 

It is noted that, also for the ampule cassettes 69 and the 
ampule containers 82, the processes described above are 
carried out similarly according to the flow charts shown in 
FIGS. 20A and 20B. 

Consumables Management Operation 

Also, in this medication collecting system, the consump- 
tion state of consumable articles (printing ink, package belt 
and the like) in the units can be detected. 

For example, the remaining quantity of the package belt 
13 which is used in the tablet dispensing station 4 is 
calculated based on an initial length and a length required 
per package. Similarly, the remaining quantity of the tape 
band 54 for the bundling machine 47 which is used in the 
tablet dispensing station 4 is calculated based on an initial 
length and a band feed quantity. Further, the remaining 
quantity of the prescription paper 101 which is used in the 
label issuing station 7 is calculated by subtracting the 
number of printed sheets from the initial setting number of 
sheets each lime a printing process is performed. The 
remaining quantity of thermal transfer ink ribbon which is 
used in the label issuing station 7 is calculated based on an 
initial length and a consumption length (the consumption 
length for six-line printing is 3.5 mm). 

Each time the consumption slate of each consumable 
article is detected in (his way, the consumable article data is 
updated and it is determined whether or not the article needs 
to be replaced. If it is decided that the article needs to be 
replaced, then an instruction that, for example, "Package 
paper will soon be out. Do you want to replenish?'*, and 
"YES/NO" keys are displayed on the display as a replen- 
ishment operating screen. If the "YES" key is chosen, then 
the replacement procedure for the relevant consumable 
article is displayed. Then, the article is replaced according to 
this procedure, and if the replacement is completed, a 
question, "Has replacement been completed?", and "YES/ 
NO" keys are automatically displayed. If the "YES" key is 
chosen, the replenishment operating screen is ended and the 
consumable article data is updated, followed by a return to 
the normal screen. 
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Automatic Bagging Station It should be emphasized that the steps following the signal 

... . , from the computer can be performed in any order and could 

An automatic bagging station shown in FIG. 21 may be . ,. i - i .u . ui . a- a 

• r i ■ + ,r occur simultaneously, ror example, the tablet dispenser 4 

adopted instead or the tray recovering station 2 (for more , ... - 1 1 . *■ ■ i. i 

details, see Japanese Patem Applications HE 10203749. HE c " nd »™P>"<; ^pcoser 5 could be operatmg amultaneously. 

10 75813 etc ) dispensing their medications when the tray 9 passes beneath 

* the respective station. If medication from tablet dispenser 4 

In this automatic bagging station, a sheet 112 wound or ampule dispenser 5 is not required, the tray simply passes 

around a roll 111 is formed into a bag shape by a sealing part t0 tnc ncxt station ^ shown in FIG 2 2. 

113 and cut into bags by a cutter 114, and the bags are ^ .^.^ m [M g ^ 

printed on the surfaces by a printer 115 and then conveyed 10 shown) ^ a ^ ^ from |w m ^ .J^ 

to a medication feed part 116. In the medication feed part , . ' 4 , , , r . 4 . . / 

^£ iLl L i j j- . .•_ < tx entering at least one person s drug prescnption information 

1 « , w.th the bags opened, med.caments wtth.n the tray 9 are ^ ^ £ m and ^rniZg tbe d 

all put mlo the bags, and after seahng the bags are accom- $cri jon informa F tion from |ne second co b m ^ , Q 

modated in a large-size tray 117 provided below the medi- r . i1ftf . „. . „ t . 

f , 4 *ru i ■ t * t ~ • j computer 119 for controlling the bulk medication dispensing 

cation iced part 116. The large-size tray 117 is conveyed 1<; , ~ , ,, n . e r . , 

sidewa s b a conve or 118 apparatus 200. Computer 119 processes the information to 

si eways y a conveyor . control the bulk medication disptnsing apparatus 200. 

Steps of the Preferred Method Th c method includes packaging of the solid medication 

23 dispensed by tablet dispenser 4 in a continuous strip 13 

Having described exemplary apparatus for practicing and div j ding thc Mrip int0 at Icasl onc dosagc unit such as 
aspect of the invention and the operation ol the apparatus we 2C {3n . ,, escribed above mac hine-readable drug prescrip- 
now turn to an example of the method. FIG. 22 is a flow lion information may be printed directly on the package. Thc 
chart which summarizes onc form of thc automated method machine-readable drug prescription information may alter- 
tor dispensing bulk medications with machine-readable natively be printed on a label applied to the package. FIG. 
code which may be practiced using the abovc-desenbed 2 3 shows an exemplary package 13a with exemplary pack- 
dispensing apparatus. 25 age j n f omial i on sucn ^ tne patient's name 121, a descrip- 

According to a first step of the preferred method, at least tion of the contents of the package 122 and a machine- 
one person's drug prescription information is provided to a readable bar code 123. Machine readable code 123 can 
computer 119 (not shown) for controlling the bulk medica- include information customized to the operator's needs 
tion dispensing system 200. Subsequently, a predetermined including patient name, doctor name, dosage instructions 
quantity of solid medication 23 is automatically dispensed 30 and other patient-specific information, 
and packaged into at least one dosage unit 13a from first method may further include the step of applying the 
bulk medication dispensing apparatus (tablet dispensing machine-readable drug prescription information to a liquid 
station 4) in response to a signal from computer 119 based medication package 67, 81 such as with the label informa- 
on the person's drug prescription information. Machine- tion shown in FIG. 24. The information is preferably printed 
readable drug prescription information is automatically on perforated adhesive-backed paper 103 such as that shown 
applied to the solid medication package 13a in response to ; n piG. 24 and can simply be peeled off of the paper and 
a signal from computer 119 based on the drug prescription applied to the liquid medication package 67, 81. FIG. 24 
information. shows exemplary information such as the patient's name 

A predetermined quantity of packaged liquid medication 124, a description of the contents of the package 125 and a 

from a second bulk dispensing apparatus (such as ampule machine-readable bar code 126 which can include informa- 

dLspenser 5) is automatically dispensed in respoase to a lion customized to the operator's needs including patient 

signal from computer 119 based on one of the person's drug name, doctor name, dosage instructioas and other patient - 

prescriplion information. Ma chine -readable drug prescrip- specific informal ion. 

tion information 103 is automatically provided for applica- a< As shown in FIG. 25, dosage instructions 101 including 

lion to the liquid medication package in response to a signal " patient identification 127 information, human-readable dos- 

from the computer based on the drug prescription informa- age instniciions 131 and machine-readable code 128 may be 

tion. And, prescription paper 101 providing information placed in tray 9 by printer 7. As in the case of the bar codes 

about thc entire filled prescription can also be provided. The [23, 126 on the packages, the codes 128 on the instructioas 

medication packages including the machine-readable drug 5C can include information tailored to the operator's request 

prescription information corresponding to the person's drug ' ' such as that described above. The machine-readable code 

prescription are then collected. necd nol be limited to bar codes and can include any suitable 

While computer 119 initiates the filling sequence, it is code, 

contemplated that there may be intermediate steps or devices The method can include further steps for utilizing the 

in the sequence by which the dispensing devices are con- s5 machine-readable code provided for thc medication = k- 

trolled. ages. Thus, for example, the method can include use of thc 

It is most preferred that the medications 23, 67, 81 be information to verify that thc correct unit dosagc has been 

dispensed into a receptacle (such as tray 9) which is moved assigned to a patient. This can be accomplished by scanning 

from dispenser to dispenser by conveyor 3 which is under the machine-readable code 123, 126 and/or 128 with any 

the control of computer 119. Following dispensing, the tray 60 suitable scanner device 129 (not shown), transmitting the 

9 is moved by the conveyer 3 to tray collection station 1 scanned code to the computer 119 and generating a signal 

where the patient-specific medication orders are collected - from computer 119 to confirm that the packages correspond 

for delivery to the patients. to the patient's drug prescription information. 

The method may also be used to dispense dosage -based Another use of the information is to verify that the correct 

medications generally and without reference to a specific 65 medication is being given to the patient, for example, at the 

patient. Such medication may be used, for example in patient's bedside in a hospital. This could be performed by 

stocking a drug formulary. a nurse prior to the patient takir:., the medication. This 
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method comprises the further steps of scanning the machine- 
readable code 123, 126 and/or 128, transmitting the scanned 
code to the computer 119, scanning machine-readable code 
130 on the person's medical records (not shown), transmit- 
ting the scanned code to the computer 119 and generating a s 
signal from computer 119 to confirm that the medication is 
suitable for the person. It is contemplated that the informa- 
tion scanned into computer 119 would be used for other 
purposes such as billing the patient or the patient's insurer 
for the medication. to 

While the principles of this invention have been described 
in connection with specific embodiments, it should be under- 
stood clearly that these descriptions are made only by way 
of example and are not intended to limit the scope of the 
invention. * 5 

What is claimed: 

1. A method for dispensing bulk prescription medications 
into dosage units together with machine-readable drug pre- 
scription information comprising the steps of: 

providing at least one person's drug ]- inscription in for- 20 
malion to a computer for controlling bulk medication 
dispensing apparatus; 

automatically dispensing and packaging a predetermined 
quantity ui ^uiid medication into at least one dosage 
unit from a first bulk medication dispensing apparatus ~" 
in response to a signal from the computer based on the 
person's drug prescription information; 

automatically applying machine-readable drug prescrip- 
tion information to the solid medication package in 
response to a signal from the computer based on the 
drug prescription information; 

automatically dispensing a predetermined quantity of 
packaged liquid medication from a second bulk dis- 
pensing apparatus in response to a signal from the 35 
computer based on the person's drug prescription infor- 
mation; 

automatically providing machine-readable drug prescrip- 
tion information for application to the liquid medica- 
tion package in response to a signal from the computer dG 
based on the drug prescription information; and 

collecting the medication packages including the 
machine-readable drug prescription information corre- 
sponding to the person's drug prescription. 

2. The method of claim 1 further including a second i5 
computer at a site remote from the computer for controlling 
the bulk medication dispensing apparatus and comprising 
the further steps of: 

entering at least one person's drug prescription informa- 
tion into the second computer; and 5c 

transmitting the drug prescription information from the 
second remote computer to the computer for control- 
ling the bulk medicalion dispensing apparalus; 
whereby the computer for controlling the bulk medi- 
cation dispensing computer uses the information to 55 
control the bulk medication dispensing apparatus. 

3. The method of claim 1 wherein the solid medicalion 
packaging step includes packaging the solid medication in a 
continuous strip. 

4. The method of claim 3 further including the step of 60 
dividing the strip into the at least one dosage unit. 

5. The method of claim 1 wherein the step of applying 
machine-readable drug prescription information to the solid 
medication package comprises printing the information 
directly on the package. 

6. The method of claim 5 wherein the machine-readable 
drug prescription information comprises a bar code. 
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7. The method of claim 1 further including the step of 
applying the machine-readable drug prescription informa- 
tion to the liquid medication package. 

8. The method of claim 7 wherein the machine -re ad able 
drug prescription information comprises a bar code. 

9. The method of claim 8 wherein the liquid medication 
is packaged in unit-of-use ampules. 

10. The method of claim 1 wherein the method further 
comprises the steps of: 

scanning the machine-readable code on the packages; 
transmitting the scanned code to the computer; and 
generating a signal from the computer to confirm that the 
packages correspond to the person's drug prescription 
information. 

11. The method of claim 1 wherein the method further 
comprises the steps of: 

scanning the machine-readable code on the packages; 
transmitting the scanned code to the computer; 
scanning machine -readable code on the person's medical 
records; 

transmitting the scanned code to the computer; and 
generating a signal from the computer to confirm that the 
medication is suitable for the person. 

12. A method for dispensing bulk prescription medica- 
tions together with machine-readable drug prescription 
information comprising the steps of: 

providing at least one person's drug prescription infor- 
mation to a computer for controlling at least bulk 
medication dispensing apparatus and conveyor appa- 
ratus for transporting medication-holding receptacles to 
and from at least one bulk medication dispensing 
apparatus; 

automatically dispensing and packaging at least one dos- 
age unit of a predetermined quantity of solid medica- 
tion from a first bulk medication dispensing apparatus 
containing a plurality of different medications in 
response to a signal from the computer based on the 
person's drug prescription information; 
automatically applying machine-readable drug prescrip- 
tion information to the solid medication package in 
response to a signal from the computer based on the 
drug prescription information; 
automatically dispensing the person's packaged, labeled 

solid medication into a receptacle on a conveyor; 
automatically dispensing a predetermined quantity of 
packaged liquid medication from a second bulk dis- 
pensing apparatus in response to a signal from ihe 
computer based on the person's drug prescription infor- 
mation; 

automatically providing machine-readable drug prescrip- 
tion information for application to the liquid medica- 
tion packages in response to a signal from the computer 
based on the drug prescription information; 
automatically dispensing the person's liquid medication 
and machine-readable drug prescription information 
into a receptacle on a conveyor; and 
transporting the receptacle on the conveyor to a receptacle 
collection area. 

13. The method of claim 12 further including a second 
computer at a site remote from the computer for controlling 
the bulk medication dispensing apparatus and comprising 

65 the further steps of: 

entering at least one person's drug prescription informa- 
tion into the second computer; and 
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transmitting the drug prescription information from the 
second remote computer to the computer for control- 
ling the bulk medication dispensing apparatus; 
whereby the computer for controlling the bulk medi- 
cation dispensing apparatus computer uses the infor- 
mation to control the bulk medication dispensing appa- 
ratus and conveyor. 

14. The method of claim 12 wherein the solid medication 
packaging step includes packaging the solid medication in a 
continuous strip. 

15. The method of claim 14 further including the step of 
dividing the strip into the at least one dosage unit. 

16. The method of claim 14 wherein the step of applying 
machine-readable drug prescription information to the solid 
medication package comprises printing the information 
directly on the package. 

17. The method of claim 16 wherein the machine-readable 
drug prescription information comprises a bar code. 

18. The method of claim 12 further including the step of 
applying the machine-readable drug prescription informa- 
tion to the liquid medication package. 

19. The method of claim 12 wherein the method further 
comprises the steps of: 

scanning the machine-readable code on the packages; 
transmitting the scanned code to the computer; and 
generating a signal from the computer to confirm that the 

packages correspond to the person's drug prescription 

information. 

20. A method for dispensing bulk medications together 
with machine-readable drug prescription information iden- 
tifying the medications comprising the steps of: 

providing drug dispensing information to a computer for 
controlling bulk medication dispensing apparatus; 

automatically dispensing and packaging in at least one 
dosage unit a predetermined quantity of solid medica- 
tion from a first bulk medication dispensing apparatus 
in response to a signal from the computer based on the 
drug dispensing information; 

automatically applying machine-readable drug identify- cc 
ing information to at least one solid medication pack- 
age in response to a signal from the computer based on 
the drug dispensing information; 

automatically dispensing a predetermined quantity of 
packaged liquid medication from a second bulk dis- i? 
pensing apparatus in response to a signal from the 
computer based on the drug dispensing information; 

automatically providing machine-readable drug identify- 
ing information for application to the liquid medication 
package in response to a signal from the computer 5c 
based on the drug dispensing information: and 

collecting the medication packages including the 
machine-readable drug identifying information. 

21. The method of claim 20 wherein the step of applying 
machine -read able drug prescription information to the solid 55 
medication package comprises printing the information 
directly on the package. 

22. The method of claim 2! wherein the machine-readable 
drug prescription information comprises a bar code. 

23. The method of claim 20 further including the step of 60 
applying the machine-readable drug prescription informa- 
tion to the liquid medication package. 

24. The method of claim 23 wherein the machine-readable 
drug prescription information comprises a bar code. 

25. A method for dispensing bulk prescription medica- 65 
tions from at least a first bulk medication dispensing appa- 
ratus for dispensing solid medication and a second bulk 
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medication dispensing apparatus for dispensing packaged 
liquid medication, said medications being dispensed into 
dosage units together with machine-readable drug prescrip- 
tion information, the method comprising the steps of: 
providing at least one person's drug prescription infor- 
mation to a computer for controlling the bulk medica- 
tion dispensing apparatus; 
if the prescription information includes solid-medication 
information, automatically dispensing and packaging a 
predetermined quantity of the solid medication into at 
least one dosage unit from the first bulk medication 
dispensing apparatus in response to a signal from the 
computer based on the solid-medication information; 

- — : -ally applying machine-readable drug prescrip- 

intormation to the solid medication package in 
response to a signal from the computer based on the 
solid-medication information; 
if the prescription information includes liquid-medication 
information, automatically dispensing a predetermined 
quantity of the packaged liquid medication from the 
second bulk dispensing apparatus in response to a 
signal from the computer based on the liquid- 
medication information; 
automatically providing machine-readable drug prescrip- 
tion information for the packaged liquid medication in 
response to a signal from the computer based on the 
liquid-medication information; and 
collecting the person's medication packages, including 
the machine-readable drug prescription information 
related thereto. 

26. The method of claim 25 further including a second 
computer at a site remote from the computer for controlling 
the bulk medication dispensing apparatus and comprising 
the further steps of: 

entering at least one person's drug prescription informa- 
tion into the second computer; and 

transmitting the drug prescription information from the 
second computer to the computer for controlling the 
bulk medication dispensing apparatus; 

whereby the computer for controlling the bulk medication 
dispeasing apparatus uses the information to control (he 
bulk medication dispensing apparatus. 

27. The method of claim 26 wherein the solid medication 
packaging step includes packaging the solid medication in a 
continuous strip. 

28. The method of claim 27 further including the step of 
dividing the strip into the at least one dosage unit. 

29. The method of claim 27 wherein the step of applying 
machine-readable drug prescription information to the solid 
medication package comprises printing the information 
directly on the package. 

30. The method of claim 25 wherein the machine-readable 
drug prescription information for application to the solid 
medication package comprises a bar code. 

31. The method of claim 25 further including the step of 
applying the machine-readable drug prescription informa- 
tion to the liquid medication package. 

32. The method of claim 25 wherein the machine-readable 
drug prescription information for application to the liquid 
medication package comprises a bar code. 

33. The method of claim 25 wherein the liquid medication 
is packaged in unit-of-use ampules. 
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34. The method of claim 25 wherein the method further 
comprises the steps of: 

scanning the machine-readable code on the packages; 
transmitting the scanned code to. the computer; and 
generating a signal from the computer to confirm that the 

packages correspond to the person's drug prescription 

information. 

35. The method of claim 25 wherein the method further 
comprises the steps of: 
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scanning the machine-readable code on the packages; 
transmitting the scanned code to the computer; 
scanning machine-readable code on the person's medical 
records; 

transmitting the scanned code to the computer; and 
generating a signal from the computer to confirm that the 
medication is suitable for the person. 



